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

[Boehm, Hans]

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Herb Sutter
> Sent: Thursday, July 05, 2007 12:49 PM
> To: C++ threads standardisation
> Subject: RE: RE: [cpp-threads] Slightly revised memory model 
> proposal (D2300)
> 
> I haven't been able to follow the deluge of recent 
> discussion, but I just reread Sarita's note from last week:
> 
> > I am assuming there is still a need to convey a simple model to the 
> > "masses" who will use locks and SC atomics (and not relaxed 
> atomics).
> > And that there isn't yet a simple enough alternative to "SC for DRF 
> > programs" for this purpose.
> 
> That was also my understanding, and that beyond that (and 
> primarily for PPC) we were also going to support a relaxed 
> model as a pure extension. In particular, a programmer who 
> doesn't touch the relaxed stuff shouldn't be affected by the 
> presence of the extensions.
> 
> Ideally, an implementer who doesn't touch the relaxed stuff 
> shouldn't be affected either (e.g., I hope the added 
> complexity in the specification would be mostly limited to 
> the extensions). I realize this may not be ideally achievable 
> but I had the impression that Hans and Clark were still 
> trying to make an effort in this direction.
> 
> Sarita continued:
> > If the above is true, then doesn't it follow that we have to define 
> > data-race-free in an SC-centric way? It then seems to 
> follow that the 
> > example below should not be classified as drf. One possible simple 
> > (not necessarily best and not yet proven correct) way to do 
> that is to 
> > say that programs with relaxed atomics (in SC executions) are not 
> > considered drf. Then immediately such programs require 
> reasoning with 
> > the more complex model, but that's the cost of using 
> relaxed-atomics. 
> > There may be other options as well that articulate limited uses of 
> > relaxed-atomics that also allow using SC-centric drf definition.
> >
> > In summary, the point I am making is that if a data race is not 
> > defined in terms of SC executions, then we lose a lot of 
> what we were 
> > after (at least in several previous discussions). In yet 
> other words, 
> > if people restricting themselves to sc atomics have to 
> reason with the 
> > complex model anyway, then it isn't clear that the 
> distinction between 
> > relaxed and sc atomics is driven by "ease-of-use."
> 
> My understanding was that we had decided to pursue a path 
> like that outlined above. I haven't seen any replies to 
> Sarita's note -- am I safe in believing that we're still on 
> the general path she describes?
Sort of.  The proposed standard (D2334) still describes a more general
model, because the SC notion of races is inappropriate by itself (see
http://www.decadentplace.org.uk/pipermail/cpp-threads/2007-June/001725.h
tml ).  But hopefully the other draft I just posted (D2335) will
convince people that the more complicated model has the right simple
properties for programs that use only lock(), unlock() and SC atomics.
I think this is isomorphic to the approach Sarita suggested in
http://www.decadentplace.org.uk/pipermail/cpp-threads/2007-June/001728.h
tml, except that the definitions remain different, and we still define
programs using weak atomics as drf, though with more complicated
semantics.

But I think that for programs not using weak atomics (and possibly
trylock) all the approaches the three of us are advocating lead to
exactly the same programming rules.  The only issue is how we define
weak atomics in the standard.

I think the approach we are currently using probably leads to the
simplest standardese.  We do end up with the simpler rules for SC
atomics in notes, and as theorems, rather than directly in binding text.
Hopefully the notes will be enough that text book authors who choose to
ignore weak atomics get the rules right.

Hans

> 
> Herb
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>