[cpp-threads] Examples of cross-thread ordering

Boehm, Hans hans.boehm at hp.com
Tue Jul 11 01:43:45 BST 2006


> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Jeremy Manson
> Sent: Monday, July 10, 2006 3:39 PM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Examples of cross-thread ordering
> 
> 
> Hi Herb,
> 
> Herb Sutter wrote:
> 
> > Example 1:
> > 
> >   // thread T1
> >   x = 1;	// a
> >   y = 2;	// b
> >   r1 = y;	// c
> > 
> >   // thread T2
> >   y = 3;	// d
> >   x = 4;	// e
> >   r2 = x;	// f
> > 
> > It is possible to have r1 == 3 and r2 == 1? How is the 
> answer derived 
> > from applying the rules in the Java and draft C++ memory models?
> 
> Java doesn't allow this result for volatiles.  All accesses 
> to volatiles need to be in a single, total order, where each 
> read returns the last write to that variable (i.e., 
> sequentially consistent).  This is not such a result.
> 
The current C++ proposal does allow this with plain atomic<>
assignments, though Herb and I were discussing whether this is the
correct default.  Currently stores only have release semantics and loads
only have acquire semantics.  Unlike Java, the current proposal is to
not insist on a total order among atomic<> operations.  You end up with

a -> b
a -> f
d -> e
d -> c

which is acyclic.  But even adding the extra Java edges it would still
be.  The difference is really the insistence on the total order.

Somewhat intuitively, the current C++ proposal allows writes to be
delayed, e.g. in a write-buffer, before they are seen remotely.  This
seems to model what hardware (particularly X96) can do cheaply.  But in
slightly weird cases like this, it gives you a less expected outcome.

Thinking about this more, it seems a bit tricky to provide both the Java
version and the current version, but I think it can be done if we want.
> 
> > 
> > 
> > Example 2:
> > 
> >   // thread T1
> >   x = 1;	// a
> >   r1 = y;	// b
> >   r2 = y;	// c
> > 
> >   // thread T2
> >   y = 2;	// d
> >   z = 6;
> > 
> >   // thread T3
> >   y = 4;	// e
> >   r3 = z;
> >   x = 8;	// f
> >   r4 = x;	// g
> > 
> > If r1 == 2 and r2 == 4 (and r3 == 6), is it possible to 
> have r4 == 1?
> 
> 
> I don't see how; it doesn't look as if there is a total order 
> that would reflect that.
Again, the current C++ proposal does not insist on the total order, and
I think this would be allowed.

> 
> > 
> > (I think that variable z, and therefore r3, seem to be 
> unnecessary and 
> > I'll write Arvind separately about that, but I include it as it 
> > appears in the original example.)
> > 
> > 
> > Example 3:
> > 
> >   // thread T1
> >   x = 1;	// a
> >   y = 3;	// b
> >   r1 = y;	// c
> > 
> >   // thread T2
> >   y = 4;	// d
> >   r2 = x;	// e
> > 
> >   // thread T3
> >   x = 2;	// f
> > 
> > If r1 == 4 and r2 == 2, what if anything can we say about a 
> > happens-before relationship between lines a and f?
> 
> 
> Not a lot.  If -> is the happens-before relationship, we can 
> say a -> b 
> -> c, d -> e, f -> e and d -> c.  If there is no other code creating
> happens-before relationships, then we can say that there 
> isn't a happens-before relationship between the two.
The way the C++ proposal is currently formulated, we lose b -> c and d
-> e.
Otherwise the answer is the same.

> 
> This is because there are two factors at work here in Java -- 
> a total order over accesses to volatiles, and the 
> happens-before order, which is determined based on program 
> order and on which volatile read sees which volatile write.  
> In the total order, line a has to occur before line f, 
> because otherwise, line e wouldn't see the value 2.  This 
> implies nothing for the happens-before order, though, because 
> a and f are both writes.
> 
> I didn't know Arvind and Maessen were still working on this 
> area -- the last I heard from them about it was 5 or 6 years 
> ago.  Where is this paper located / published?
> 
> 					Jeremy
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
> 



More information about the cpp-threads mailing list