[cpp-threads] Sequential Consistency redux

[Boehm, Hans]

> From: Alan Stern
> Sent: Monday, November 21, 2011 1:13 PM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Sequential Consistency redux
> 
> On 21 Nov 2011, N.M. Maclaren wrote:
> 
> > On Nov 21 2011, Paul E. McKenney wrote:
> > >
> > >> Amusingly, this case shows that the note in 1.10p12 is misleading,
> and
> > >> is therefore inappropriate!  Notes are there for clarification,
> and
> > >> that one doesn't clarify ....
> > >
> > >What would you suggest as an alternative?  If I recall correctly,
> > >the history is that one of the Cambridge guys (Mark Batty, I
> believe)
> > >came up with a litmus test that was permitted in absence of 1.10p12.
> > >This litmus test motivated the addition of 1.10p12.
> >
> > Oh, it's not the normative text I am talking about, but just the
> Note.
> > I would just drop the Note.
> 
> In what respect is the note misleading?
> 
> It's worth mentioning that even before the "litmus test" was devised
> and 1.10p12 was added, it was felt that the text would rule out the
> sort of non-sequentially-consistent behavior of mutexes you asked
> about.
Yes.  Other cycles are arguably impossible because they prevent a read access from seeing any write.  If an atomic release write R is seen by a corresponding acquire operation A, and they occur in a happens-before cycle, we immediately get a contradiction, because R is not in the visible sequence of side-effects with respect to A.  Thus such executions aren't allowed.  30.4.1.2p5 arguably applies this to locks as well.  That aside, it could be argued that the note actually doesn't add much insight for the typical reader.  Thus I no longer feel strongly about this one way or another.
> 
> (On the other hand, even now I think the text could stand a little more
> clarification.  1.10p8 says "All operations on a given mutex occur in a
> single total order", but it doesn't say explicitly that this order must
> be consistent with "happens before".  Contrast this with the way 1.10p6
> talks about the relation between an atomic object's modification order
> and "happens before".)
Again, I don't see how this could fail to be satisfied.  I don't believe there is a way to get a cycle in happens-before union mutex-order without violating the other constraints.  The other constraints on mutexes are such that mutex-order is a subset of happens-before.  (Outermost acquires and releases must alternate.  The acquire -> release edges contribute to sequenced before, and release -> acquire contribute to synchronizes-with.)

Hans

> 
> Alan Stern
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadent.org.uk
> http://www.decadent.org.uk/cgi-bin/mailman/listinfo/cpp-threads