Re: making GStaticMutexes faster

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Owen,

> > recently I had an email discussion with Tim about GStaticMutexes,
> > which now have a really big overhead, because before every access to
> > them (locking, unlocking) another mutex has to be locked.
> 
> Not on operating systems with POSIX thread support, right?

Yes, so it of course is kind of a non issue.

> > This is super paranoid, as the only case it might fail without this
> > additional lock is on an MP-machine without cache coherence, which
> > should not only be very rare.
> 
> I think "cache coherence" is a topic, not a particular property...

I'm sure there is not a very coherent literature on that topic ;-) But the
definition we're teaching here at our Uni (I recently made exercise course for
that, so I actually ought to know, but I had to "double check" as well ;-) is:

A cache memory system is called coherent, if the data read by a random
processing element always is the value lastly written to that location by any
processing element. (Forgive my pidgin translation)

[ So two caches need not be consistent ("equal" on shared locations),
  just coherent. This is solved by bus sniffing with e.g. MESI. ]

> The particular property you are proposing relying on is if processor
> #1 writes location A and then location B, then another processor will
> never see a write to location B then a write to location A.

Yes, that's what we need here.

> (Since the writes are here separated by a function return it is
> pretty unlikely that instruction reordering would cause problems,
> so it probably is mostly a question of cache behavior, yes.)

This is no problem, as we still can have the write to *mutex after the memory
barrier after creating the mutex.

And, even though I know, that it doesn't prove anything: Douglas Schmidt's ACE
also uses this technique, and ACE is quite portable. 

http://ace.cs.wustl.edu/cvsweb/ace-cvs.cgi/ACE_wrappers/ace/Singleton.cpp

There is also a paper by Schmidt on that subject, though a bit dated:

http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf

> I don't have any more information than what I had back when we
> originally discussed this topic, which is that it is not safe
> "in general" without an explicit memory barrier, and it is safe
> on the common ia32 processors. I still have no idea on what
> set of processors / machines it will fail on.

> > And yes, this makes a difference, GStaticMutex suddenly becomes ~ 3
> > times faster on platforms without native static mutexes.
> 
> How common are such platforms?

Trying to remember the Be patches, I saw some time ago (BTW what happened to
them), they seem to have no native static mutex, also Windows doesn't have it
(at least on 9x IIRC), but we still have no native implementation there
anyway.

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi