[cpp-threads] Slightly revised memory model proposal (D2300)

[Boehm, Hans]

> -----Original Message-----
> From: Paul E. McKenney [mailto:paulmck at linux.vnet.ibm.com] 
> Sent: Friday, June 22, 2007 5:50 PM
> To: Boehm, Hans
> Cc: C++ threads standardisation; Sarita V Adve
> Subject: Re: [cpp-threads] Slightly revised memory model 
> proposal (D2300)
> 
> On Sat, Jun 23, 2007 at 12:16:55AM -0000, Boehm, Hans wrote:
> > 
> > > -----Original Message-----
> > > From: cpp-threads-bounces at decadentplace.org.uk
> > > [mailto:cpp-threads-bounces at decadentplace.org.uk] On 
> Behalf Of Paul 
> > > E. McKenney
> > > Sent: Friday, June 22, 2007 10:37 AM
> > > To: C++ threads standardisation
> > > Cc: Sarita V Adve
> > > Subject: Re: [cpp-threads] Slightly revised memory model proposal 
> > > (D2300)
> > > 
> > > On Fri, Jun 22, 2007 at 10:08:50AM -0700, Paul E. McKenney wrote:
> > > > On Fri, Jun 22, 2007 at 02:22:30AM -0000, Boehm, Hans wrote:
> > > 
> > > [ . . . ]
> > > 
> > > > > 1.10p10:
> > > > 
> > > > [ . . . ]
> > > > 
> > > > >     A multi-threaded execution is consistent if each
> > > thread observes
> > > > >     values of objects that obey the following constraints:
> > > > > 
> > > > >         * No evaluation happens before itself.
> > > 
> > > One more thing...  This was added in the revision, but 
> the node has 
> > > not been updated to give the rationale.  Seems intuitive 
> enough at 
> > > first glance, but more thought quickly leads to questions like 
> > > "which part of the evaluation?" and "from the viewpoint of which 
> > > component of the system?".
> > > 
> > > So, what is this really trying to say, and what mishaps 
> is it trying 
> > > to prevent?
> > > 
> > My understanding is that "evaluation" here is basically standardese 
> > for "memory access".  (Clark wrote that part, and still has 
> to make a 
> > pass through some of my changes.)  "Happens before" is the relation 
> > defined in 1.10p8.  So this is basically saying that that relation 
> > consistently orders memory accesses.  I added a bit more 
> text to the 
> > subsequent note, and corrected the numbering in that note.  Today's 
> > version is attached, this time even with the correct date.
> 
> OK, memory accesses not happening before themselves does make sense.
> I think.  ;-)
> 
> Taking a very quick look at the new version:
> 
> o	Isn't the addition of "sequentially consistent ordered stores"
> 	to the "synchronizes with" relation redundant given that ordered
> 	stores have both acquire and release semantics and that "happens
> 	before" is transitive?
Sequentially consistent stores only have release semantics, but they
have the additional constraint that all sequentially consistent atomic
operations appear in a single total order, and that loads must see the
last preceding store in that order.  They don't have acquire semantics.
In the current formulation, acquire semantics wouldn't make sense since
whether or not an acquire operation introduces a synchronizes with
relationship depends on the value read, and there is no such thing here.
> 
> o	As noted in earlier email, I still would like to see relaxed
> 	RMW operations excluded from propagation of "synchronizes with".
I finally replied to that in the preceding message.
> 
> o	In 1.10p10 fourth major bullet, "Ms modification order" 
> should be
> 	"M's modification order".
Thanks.  Fixed.
> 
> 						Thanx, Paul
>