[cpp-threads] Somewhat relevant technical report

[Boehm, Hans]

I think we're trying to say different things, and perhaps the footnote
should be rephrased.

We basically have, in Posix terms:

T1: v1 = 1; pthread_mutex_lock(&l1);

T2: pthread_mutex_trylock(&l1) fails; r2 = v1;

The question is whether r2 is guaranteed to be 1.

As I see it, the only reason this might not be guaranteed is that
pthread_mutex_try_lock doesn't guarantee memory synchronization in this
case.

It's unclear what that statement means.  Presumably it means that r2 =
v1 may effectively appear to occur before the pthread_mutex_trylock()
call, and thus there may be a race, and the behavior may be undefined as
a result.  Inserting a pthread_mutex_lock(&l2);
pthread_mutex_unlock(&l2); should ensure that memory is "synchronized"
between the trylock and the assignment to r2.  Hence this race can no
longer occur, and the resulting example should behave like the one in my
toy language, and it should guarantee r2 = 1.  (This of course requires
a release barrier for pthread_mutex_lock(), which was the point.)

The modification based on barriers will make it work correctly with
something like the modification you proposed for XBD4.10, and will no
longer require the release constraint in pthread_mutex_lock().  But
AFAIK none of that is part of the standard.  And the current standard
does technically require that release constraint.  The version you
proposed would technically be a substantive change, though I doubt
anyone would notice (aside from the fact that some implementations might
become faster).

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Alexander Terekhov
> Sent: Friday, December 16, 2005 3:55 AM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Somewhat relevant technical report
> 
> 
> On 12/15/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> > Report HPL-2005-217, "Reordering Constraints for 
> Pthread-Style Locks", 
> > became available at 
> > http://www.hpl.hp.com/techreports/2005/HPL-2005-217.html .
> >
> > This basically asks and answers the question of what memory 
> fences are 
> > required by pthread locks, if you try as much as possible 
> to take the 
> > current spec at face value.  (Pthread_mutex_lock() requires a full 
> > barrier, pthread_mutex_unlock() doesn't.)
> 
> At face value, pthread_mutex_trylock() doesn't synchronize on 
> failure and I disagree that "example could easily be made 
> Posix conforming by adding a lock(l2); unlock(l2); 
> immediately after the while loop, where l2 is otherwise 
> unused". Under my interpretation of (busted) XBD 4.10, 
> example could easily be made Posix conforming using 
> pthread_barrier_t and
> pthread_mutex_lock() doesn't require a full barrier.
> 
> initially: pthread_barrier_init(&b, 0, 1);
> 
> T1: v1 = 1; pthread_barrier_wait(&b); lock(l1);
> 
> T2: r1 = try_lock(l1);
> while (r1) { unlock(l1); r1 = try_lock(l1); } 
> pthread_barrier_wait(&b); r2 = v1; out(r2);
> 
> regards,
> alexander.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>