$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.