Global refresh_version not protected against races

I think this ends up being mostly all protected by a mutex.. but converting to atomic variable to avoid having to do some horrible audit of scary code paths

> I think this ends up being mostly all protected by a mutex..

Hmm, good point. What mutex would that be?

On Wed, 22 Jun 2011 22:43:09 -0000, Olaf van der Spek <email address hidden> wrote:
> > I think this ends up being mostly all protected by a mutex..
>
> Hmm, good point. What mutex would that be?

previously I would have said LOCK_open.... but I can't remember how much
of it we've ripped out.

Quickly chatting to Brian the other day he suggested that a) it's okay
for this to be lossy and b) otherwise it may kill performance.

So we may need to look into it further.

--
Stewart Smith

Hmm, are atomics that bad for performance?

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
>

On Sat, Jun 25, 2011 at 6:02 AM, Mark Atwood <email address hidden> wrote:
> 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.

AFAIK that's not true. Cache coherence mechanisms allow you to only
'sync' a tiny bit of address space.

Olaf