[cpp-threads] C++ memory model

[Mark Batty]

Regarding 29.3p9, it seems to me that banning hoisting in this case is
an overly strong restriction, it also restricts a specific
optimization technique rather than describing an abstract set of
behaviours. 1.9p1 (the "as-if" rule) precludes any hoisting if it
would result in a different set of observable behaviours. I therefore
agree that the sentence should be dropped from the standard.


I am most concerned with 29.3p8 at the moment. The intention of the
paragraph is to impose extra ordering on the memory operations, but
this restriction is applied on top of the memory model rather than
incorporated into it. As it stands, the memory model does not have any
notion of control flow, data dependence or condition statements, so
there is not enough information within it to impose this extra
ordering.

I have been exploring the idea of making this extra information
visible to the memory model by adding fences that are strong enough to
order relaxed memory operations where they are needed. I had expected
to post this for discussion here, but unfortunately my idea reduces
the observable behaviours and therefore does not work. A test came out
of these thoughts and I would like to see what the consensus is on
what is allowed:

I believe this test should allow r1 == r2 == 42:

Thread 1:
r1 = y.load(memory_order_relaxed);
if (true) x.store(r1, memory_order_relaxed);
Thread 2:
r2 = x.load(memory_order_relaxed);
if (true) y.store(42, memory_order_relaxed);


Mark



On Wed, Sep 23, 2009 at 1:41 AM, Lawrence Crowl <crowl at google.com> wrote:
> 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
>