[cpp-threads] Re: A hopefully clearer document on POSIX threads

[Boehm, Hans]

[Returning to another old message ... ]

I believe that the current strawman proposal states that the assertion
can fail if

- Ordinary loads and stores are involved (obviously, there are many
races).

- If all the loads and stores are atomic, but unordered.  The load of x
in P1 still happens-before the store of y, since the latter depends-on
the former.  But the same is not true for the loads in P2, since
currently only stores depend-on loads.

If additionally the load of y in P2 is an acquire load, then the
assertion is guaranteed to succeed.

This means that for now, X86 load_acquires can be ordinary loads.  If
any future X86 processors fail to enforce this sort of transitivity,
then that will no longer be the case, and load_acquire will need a more
expensive implementation, as will Java volatile loads.

I'm personally OK with all of this.  Is everyone else?

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Nick Maclaren
> Sent: Monday, February 20, 2006 12:17 AM
> To: C++ threads standardisation
> Cc: Valentin Samko
> Subject: Re: [cpp-threads] Re: A hopefully clearer document 
> on POSIX threads 
> 
> Doug Lea <dl at cs.oswego.edu> wrote:
> > 
> > > But what about the causality example raised some months 
> ago here? In
> > > particular:
> > > 
> > >   initial: x = y = 0;
> > > 
> > >   P0: x = 1;
> > > 
> > >   P1: if( x == 1 ) y = 1;
> > > 
> > >   P2: if( y == 1 ) assert ( x == 1 ); // can P2 see y==1 
> before x==1?
> > > 
> > 
> > When I asked, people from Intel and AMD told me that this does have 
> > the desired effect now, but don't promise it in the future. 
> As I said the first time around,this is not a big deal in 
> practice, but makes the specs much messier.
> > For Java, we'll probably have to revisit this when non-conforming 
> > processors arise, if they ever do. For C++, I suppose it is a good 
> > idea to assume lack of transitivity to begin with.
> 
> Well, that example may not be a big deal, but the generic problem is.
> One of my users had a problem that I deduced had to be that effect.
> I can assure you that explaining it was not easy.
> 
> C++ should certainly assume lack of transitivity in unsynchronised
> basic operations, but one of the issues I raised some time 
> back is that the problem ALSO applies to synchronisation.  In 
> particular, POSIX's wording means that it could apply even if 
> you plaster the above code with mutex locks.
> 
> My experience of using parallelism and dealing with users who 
> do is that few people are capable of getting their minds 
> around a lack of transitivity in this respect.  In fact, most 
> people will naively assume global parallelism, and that is 
> something that they plain can't have - not if scalability is an issue.
> 
> 
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service, New Museums Site, 
> Pembroke Street, Cambridge CB2 3QH, England.
> Email:  nmm1 at cam.ac.uk
> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>