linux-traipu team mailing list archive
-
linux-traipu team
-
Mailing list archive
-
Message #00707
Re: [Bug 751191] Re: Global refresh_version not protected against races
Yes. It is the nature of the beast. Every time any thread hits any
mutex or other lock-like thing, every processor in the shared memory
space has to drain it's pipeline and sync all it's caches with memory.
They all have to do this, even if the lock isn't engaged. Just
checking it will do this. And, to make it even worse, the more
processors you have, more expensive this is to do.
On Fri, Jun 24, 2011 at 1:51 AM, Olaf van der Spek <olafvdspek@xxxxxxxxx> wrote:
> Hmm, are atomics that bad for performance?
>
> --
> You received this bug notification because you are a member of Drizzle-
> developers, which is subscribed to Drizzle.
> https://bugs.launchpad.net/bugs/751191
>
> Title:
> Global refresh_version not protected against races
>
> Status in A Lightweight SQL Database for Cloud Infrastructure and Web Applications:
> Fix Committed
>
> Bug description:
> Global var (g_)refresh_version is not protected against any races.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/drizzle/+bug/751191/+subscriptions
>
--
You received this bug notification because you are a member of UBUNTU -
AL - BR, which is subscribed to Drizzle.
https://bugs.launchpad.net/bugs/751191
Title:
Global refresh_version not protected against races
Status in A Lightweight SQL Database for Cloud Infrastructure and Web Applications:
Fix Committed
Bug description:
Global var (g_)refresh_version is not protected against any races.
To manage notifications about this bug go to:
https://bugs.launchpad.net/drizzle/+bug/751191/+subscriptions
Follow ups
References