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

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-04-27 17:46:21

>Peter Dimov <pdimov_at_[hidden]> wrote:
> Matt Hurd wrote:
> > Have a load_load, load_store, store_store, store_load primitive set of
> > functions for memory barriers [...]
> 
> The "unidirectional label" model proposed by Alexander Terekhov is better.

Not sure what that is.  I'll google it up.
 
> > I think we need to assume that lock/unlock synchronisation of a
> > non-null mutex is a full barrier.  Is that correct?
> 
> No, lock+unlock is not a full barrier, although it imposes ordering with
> respect to another lock+unlock on the same mutex.

OK.  Lock / unlock is a full barrier on ia32, but I see it isn't on
many other arch.

> > [...] This will become increasingly
> > important in developing, so called, lock free methods.  I call them
> > "so called" as they usually require memory model guarantees through
> > barriers or atomic ops, such as CAS, and these can be very expensive
> > on some architectures.  Lock free algorithms are often more
> > complicated and if the non-locking concurrency costs are sufficiently
> > high the benefits can quickly dissipate.  For example, locking
> > operations on an intel P4 are expensive.  On an Athlon and ia64 they
> > are considerably cheaper by more than a factor of two.
> 
> The canonical definition of "lock free" is that the system as a whole always
> makes progress. An ordinary lock-based algorithm does not have this
> property; if the thread that obtained the lock suddenly dies, no other
> thread can move past that lock.

Thanks for clearing up the definition.  Though I do find it confusing
as I've seen people call stuff lock-free where the approach uses
versioning and retry semantics based on an optimistic concurrency
approach.

Matt.