[cpp-threads] Another strawman memory model proposal

Peter Dimov pdimov at mmltd.net
Wed May 11 01:30:24 BST 2005


Boehm, Hans wrote:

> 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.

1.9/18 says that in

a, b

there is a sequence point after the evaluation of a. It is implied that this 
sequence point separates the evaluations of a and b. The wording could've 
been clearer, but it's hard to argue that it says something else.

In your expression, there is a sequence point between 'a' and 'b' because of 
1.9/18, a sequence point after the arguments have been evaluated and before 
f has been called, and a sequence point after f has returned but before the 
execution of any other expressions in the calling function. The latter two 
are due to 1.9/17. If you add the ; the expression becomes a full expression 
and one more sequence point appears after its evaluation is complete 
(1.9/16).

Anyway, the current wording is good enough for the core working group, so 
can't we just assume that it makes sense and proceed based on that 
assumption. :-)

> 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.

The sequence point in the middle says that (a, b) precedes (c, d). a c b d 
is allowed by your interpretation, but not allowed by the standard.

> Unfortunately, I'm also becoming convinced that this is a moot point,
> since we need to deal with unordered atomics.

To balance things out, I'm becoming convinced that your original approach of 
shooting for SC normal form (and relegating the atomics to "formally 
undefined but we all know what they mean" land, currently occupied by 
pthreads) may be the only practical approach. 





More information about the cpp-threads mailing list