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

Paul E. McKenney paulmck at linux.vnet.ibm.com
Wed Jun 27 18:55:57 BST 2007


On Tue, Jun 26, 2007 at 07:32:38PM -0000, Boehm, Hans wrote:
>  
> 
> > -----Original Message-----
> > From: Sarita V Adve [mailto:sadve at cs.uiuc.edu] 
> > Sent: Tuesday, June 26, 2007 11:06 AM
> > To: Boehm, Hans; C++ threads standardisation
> > Subject: RE: [cpp-threads] Slightly revised memory model 
> > proposal (D2300)
> > 
> > Hans,
> > 
> > It was good to see you at FCRC.
> > 
> > (1) There are a few comments from the previous round that are 
> > still not addressed here. For example, the definition of 
> > "consistent" does not seem sufficient to guarantee SC for 
> > some reasonable (non-controversial?) classes of programs. I 
> > assume you want
> > T1: if (A==1) B=1;
> > T2: if (B==1) A=1
> > to be considered as data-race-free and so appear SC 
> > (initially A, B are 0 and neither is atomic). However, I 
> > don't see anything in the consistency definition that will 
> > preclude both T1 and T2 reading 1 and writing 1. This has 
> > nothing to do with any definition of happens-before since SC 
> > executions of this program do not have any conflicting accesses. 
> I see the problem.  We attempted to address this in ancient versions of
> the model but somehow this got lost.  Thanks for catching it (again).
> 
> We are sort of addressing the corresponding issue for relaxed atomics,
> after Jeremy pointed it out.  But this form is clearly even more
> important.
> 
> I will either post a revision or give you a call after thinking about it
> a bit.

I have to ask...  If A and B are non-atomic ("neither is atomic"),
are we really making any guarantees whatsoever?

> > There are other issues, but may be moot in case I am 
> > misunderstanding your intent for the above. Perhaps it will 
> > be easier to talk on the phone since this has come up a few times?
> > 
> > (2) Has someone verified from IBM architects that Peter 
> > Dimov's fetch_add example actually works with PPC? Otherwise, 
> > that's a lot of complexity in the new synchronizes-with 
> > definition for no return. Sorry to not have got back to you 
> > and others on this aspect earlier, but I am not sure the 
> > current modification is the best one for this (need IBM's 
> > answer before further discussion on this).
>
> Good question.  There are some other cases currently under discussion
> where I also don't fully understand the hardware constraints.  It's
> unclear whether this should apply to "relaxed" RMW operations.  My
> feeling is that we should provide whatever guarantees we can without
> making this much more complicated still, or making it effectively
> unimplementable on common hardware.

Peter Dimov's example should work with PPC (due to B-cumulativity, FWIW)
-- in other words, on PPC the assertion should never fail.  Including the
example for reference, just to make sure we are talking about the same
example:  ;-)

T1: x=1; fetch_add_release(&v,1);
T2: y=1; fetch_add_release(&v,1);
T3: if (load_acquire(&v)==2) assert (x+y==2);

Note that x & y need not be atomic, as there are no data races.

We can get a formal analysis from the PPC architects, if that would
be useful.

						Thanx, Paul

> Hans
> 
> > 
> > Sarita
> > 
> > 
> > > -----Original Message-----
> > > From: Boehm, Hans [mailto:hans.boehm at hp.com]
> > > Sent: Thursday, June 21, 2007 9:23 PM
> > > To: C++ threads standardisation
> > > Cc: Sarita V Adve
> > > Subject: RE: [cpp-threads] Slightly revised memory model proposal 
> > > (D2300)
> > > 
> > > Here are the latest revisions of:
> > > 
> > > The D2300 memory model.  I sort of followed Lawrence's 
> > semi-suggestion 
> > > and included sc stores (not loads) with RMW operations in defining 
> > > synchronizes with.  I also cleaned up the discussion of race-free 
> > > executions in a way that I think is necessary, but may 
> > require Clark 
> > > to clean up after my standardese again.
> > > 
> > > Some text (mm_rules) to be included in the atomics proposal 
> > to explain 
> > > how it meshes with the memory model.
> > > 
> > > The sequential consistency proof updated to reflect the 
> > memory model 
> > > revisions, and hopefully fixing some other issues.
> > > 
> > > Further bug reports would be appreciated.  The C++ paper 
> > deadline is 
> > > officially tomorrow.
> > > 
> > > Hans
> > > 
> > 
> 
> --
> 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