[cpp-threads] C++ memory model

[Lawrence Crowl]

On 9/22/09, Boehm, Hans <hans.boehm at hp.com> wrote:
> > From: Lawrence Crowl [mailto:crowl at google.com]
> > On 9/22/09, Boehm, Hans <hans.boehm at hp.com> wrote:
> > > I still have a general problem with all forms of this sentence,
> > > in that it doesn't seem to be a constraint on observable program
> > > behavior.  The program can't tell whether it was moved out
> > > of the loop or just held in a local store buffer indefinitely.
> >
> > Agreed.
> >
> > > It seems to me that the most we can really properly state is
> > > precisely what's already said in the preceding sentence.
> >
> > Are you saying you would like to change the preceding sentence?
>
> No.  I like the first sentence in 29.3p9:
>
> "Implementations should make atomic stores visible to atomic loads
> within a reasonable amount of time"
>
> It's a bit vague, arguably doesn't formally constrain
> implementations, but I think it gets the essential idea across.
> Certainly if you move an an atomic store to after an infinite
> loop, this sentence makes it clear that you're doing something we
> don't recommend.  If you hoist an atomic store of a constant value
> to before such an infinite loop, you have similar issues if the
> atomic variable may be modified by another thread.  On the other
> hand, hoisting an atomic store of a constant to before the loop,
> when there can be no simultaneous assignments to that variable
> seems fine, and this senetence doesn't appear to prohibit it.
>
> I'd like to just delete the second senetnce:
>
> "Implementations shall not move an atomic operation out of an
> unbounded loop."

Okay.  Procedurally, I can slide the wording changes for chapter
29 into my omnibus atomic issues paper.  I'd rather not try and
put the 1.10 changes into that paper.  Can someone write that up?
I am pretty swamped right now.

-- 
Lawrence Crowl