[cpp-threads] Does pthread_mutex_lock() have release emantics?

[Boehm, Hans]

> -----Original Message-----
> From: Peter Dimov
> Sent: Friday, May 06, 2005 3:52 PM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] Does pthread_mutex_lock() have 
> release emantics?
> 
> 
> Boehm, Hans wrote:
> > The definition in the current draft has the advantages that:
> >
> > a) It's much simpler since we don't need to explicitly define the 
> > "happens-before" relation.  (It's also quite possibly too 
> simple once 
> > we add atomic operations.  But a really simple rule for the 
> majority 
> > of programmers who will hopefully only use locks would be nice.)
> 
> A memory model that requires fully-fenced (even on failure) 
> synchronization 
> primitives and fully-fenced atomic operations... is not a 
> good idea. :-) 
> 
I think the pthreads-like model actually doesn't.  It is stated
that way, but I think acquire end up being sufficient for an
atomic load and release for an atomic store (provided atomic
operations themselves are sequentially consistent).  And I think
pthread_mutex_unlock only requires release, since there is no way
for it to be on the receiving end of race-free inter-thread
communication.

Sarita mentioned that her thesis contains some relevant results.
(See  http://www.cs.uiuc.edu/~sadve/Publications/thesis.pdf.)
I haven't had a chance to look at that, yet. 

Even if we go with a more Java-like model, I think it's critical
to understand this, since it affects which pthreads programs
we will be breaking.

Hans