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.