Re: [boost] Re: TR2 and C++0x heads up

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-04-28 10:53:35

>Alexander Terekhov <terekhov_at_[hidden]> wrote:
> 
> Matt Hurd wrote:
> [...]
> > > The "unidirectional label" model proposed by Alexander Terekhov is better.
> >
> > Not sure what that is.  I'll google it up.
> 
> http://tinyurl.com/aj9xa
> http://tinyurl.com/72ukl
> 
> regards,
> alexander.

Thanks Alexander.  Your level of comprehension is way beyond mine. 
Especially after the dizziness of following your links :-)

I think there is a place for your detailed approach, however I do
think the majority of users are simple folk like myself and
straightforward load/store/full fences will be the appropriate level
of optimization at the step after needing more performance than
regular locking.

I'd imagine a taxonomy of sophistication something like... single
threaded -> concurrency via frameworks and patterns -> using just
mutexes and locks directly -> using barriers appropriately -> going
down the rabbit hole into dd,cc,hoist,acq,rel land with Alex... ;-)

That said, for naive users do you have an opinion on the memory
semantics locking and unlocking a mutex should provide to deliver "the
least surprise" to a user.  x86 and sparc deliver a full fence for
these AFAIK but I worry that memory visibility could cause seemingly
safe mutex protected code to trip up on weaker memory models due to
memory visibility surprises from point of view of those from the great
unwashed x86 land (like me).  I'm thinking that a PBD could provide
full fence (or perhaps just a store fence is appropriate on releasing
a lock to deliver least surprise) semantics by default that may be
overridden by explicit policy by an aware user.  Your thoughts on
memory vis requirements for locking and unlocking mutexes for the
least surprise?

matt.