Comment 5 for bug 751191

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 <email address hidden> 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
>