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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-27 15:37:08

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.

> 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.

> [...] 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.