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

[Paul E. McKenney]

On Sun, Jun 24, 2007 at 03:04:08AM -0000, Boehm, Hans wrote:
> > -----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.

Got it!  Just as sequentially consistent loads only have acquire
semantics, at least from a pure acquire/release viewpoint.  I withdraw
my objection.

						Thanx, Paul

> > 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
> >