[cpp-threads] C++ memory model

[Nelson, Clark]

> > The added sentence is okay in direction, but the wording does
> > not reflect the fact that the standard likes "shall" and the
> > standard likes to specify whether requirements are on the
> > implementation or the program.  I would rewrite that statement as:
> >
> >     The implementation shall not move an atomic side effect contained
> >     in a substatement of one of the iteration statements specified in
> >     6.5 out of the substatement.
> 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.  It seems to me that the most we can
> really properly state is precisely what's already said in the preceding
> sentence.
> 
> I think this sentence should just disappear.
> 
> Does Clark have an opinion?

There are two things that are fairly clear to me.

First, we can't change "atomic operation" to "atomic side effect". The whole point of that sentence is that an atomic object can be changed by another thread without a data race (and therefore without undefined behavior), so if there's an atomic read in a loop, it has to stay in the loop.

Second, we can't talk exclusively in terms of the substatement of a loop, because an atomic read can meaningfully appear in a loop's controlling expression, or in the continuation expression of a for-loop.

One thing that's not at all clear to me is exactly what the sentence currently in the WD is trying to say. In any event, it doesn't relate directly to 6.5p5: that paragraph is explicitly talking about loops that *don't* already contain an atomic operation (among other things), so the rewrites proposed so far basically say that an atomic operation can't be moved out of a loop that doesn't contain one. (Which is true, come to think of it, but not very useful.)

At this point it would be helpful if the person who wrote that sentence would please stand up and explain it. :-) Hans may well be right that it's not really saying anything useful.

Clark