[cpp-threads] Another strawman memory model proposal

[Peter Dimov]

Boehm, Hans wrote:

> I don't quite understand where this is going.

I'll try to explain. The relevant portion replicated for reference:

>> The C++ memory model in SCNF is, in its entirety:
>>
>> - 1.9/8 does not apply to functions that are executed in a
>> separate thread.
>>
>> - The second sentence of 1.9/17 does not apply to functions that are
>> executed in a separate thread.

[...]

> My current understanding of sequence points (thanks to your help)
> is basically:
>
> The statement "There is a sequence point between A and B"
> really means:
>
> "The set of acceptable sequential executions is hereby restricted
> so that all actions in A appear to this thread to execute before
> all actions in B.  The same applies to side effects as observed
> by a synchronous outside observer"

No. There is no "this thread", the wording is global, and the outside 
observer only observes reads/writes to volatile variables and calls to 
standard I/O functions, not all side effects.

The statement means: there exists a point in the execution sequence such 
that all side effects of A are complete and none of the side effects of B 
have taken place. Exactly what the standard says. I don't see why you need 
to rephrase it; it's clear enough to me.

> Note that this statement is not symmetric in A and B.
>
> When 1.9/7 talks about previous and subsequent evaluations, it is
> referring only to those that are explicitly ordered with respect to
> the sequence point by one of the statements of the above form.  In
> particular, there are likely to be many evaluations that are neither
> "previous" nor "subsequent".

Not many, unless we admit threads as I propose.

> Sequence points in the standard order all evaluations of
> subexpressions of an expression A with respect to all subevaluations
> of an expression B.
>
> Does that sound right?

Right.

> If we can figure out a way to leverage this to define a sequentially
> consistent execution, that would be great.  (I'm not yet sure that
> we want to talk about sequential consistency in the final version of
> the standard.  But I suspect that if we can't define that, we're
> sunk.)

The current description of the abstract machine assumes a sequentially 
consistent execution. We don't need to do anything else _unless_ we want to 
go beyond SCNF and define the behavior of sequentially inconsistent 
programs. Which will be hard.

> I think that unavoidably means adding reads to the discussion of
> sequence points.  Consider
>
> Thread 1:
> lock(l); x = ...; unlock(l)
>
> 2 options for thread 2:
> Thread 2a:
> f((lock(l), 17), x, (unlock(l), 42));
>
> Thread 2b:
> g((lock(l), r1 = x, unlock(l), r1));
>
> There is a race between Thread 1 and Thread 2a.  There is no
> race between Thread 1 and Thread 2b.  We need to capture that
> difference, since we want the first case, but not the second,
> to exhibit undefined behavior.

The 1/2a example has undefined behavior because of Clause 5 paragraph 4. The 
scalar object x is (potentially) modified by thread 1 and accessed by thread 
2a without the two being separated by a sequence point. This is an MT 
version of

    f( x = ..., x, 42 )

which is similarly undefined for the same reason.