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

[Nick Maclaren]

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