[cpp-threads] Another strawman memory model proposal

[Boehm, Hans]

[This is awfully pedantic, but I think we'll have to deal with it
eventually.  Sorry about that.]
> -----Original Message-----
> From:  Peter Dimov
> 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.
My objection to 1.9/7 is entirely to the use of the words "previous"
and "subsequent" as though they were defined terms at that point.
They are really parameters to the assertion that there is a sequence
point.  It's not meaningful to state that there is a sequence point
after the evaluation of a in

f((a, b), c)

I also have to tell you that the sequence point is between a and b,
and hence evaluations of a and b are ordered, but not a and c.
> 
> > 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.
The only way I can interpret this consistently is that the statements
about the existence of a sequence points are local, but the ordering
is transitively closed.  Thus if I see

((a, b), (c, d))

The sequence point after a orders evaluations of a and b, the sequence
point between c and orders c and d, and the sequence point in the middle
states that a precedes c and b precedes d.  Thus most individual
statements
about sequence points involve a small fraction of the evaluations. 
> 
> > 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. 
> 
I now understand better where you are going.  Thanks.  I still have
some concerns, though.

Unfortunately, I'm also becoming convinced that this is a moot point,
since we need to deal with unordered atomics.  So perhaps we can defer
the rest of this discussion until we're sure it matters.

Hans