[cpp-threads] memory model

[Peter Dimov]

Boehm, Hans wrote:
>> -----Original Message-----
>> From: Peter Dimov
>>
>> - the remark about f((a, b), c) is redundant and probably needs to be
>> removed. There is a sequence point between a and b, and there are no
>> sequence points between (a, b) and c.
> I'd love to do that.  I really don't want to deal with this stuff.
> But I'm not convinced I can.  I just did a search through the current
> standard from the committee web site, and all the text that mentions
> sequence points is written as though they were particular points
> in a sequential program execution, with a total order between all
> operations in the execution.

I don't believe that total order is implied anywhere. Function invocation is 
the canonical example of lack of total order. There are no sequence points 
between the evaluation of the arguments. In your example f( (a, b), c ), the 
comma operator introduces a sequence point between a and b, but this 
sequence point only orders a and b, not c.

(a, b) + (c, d) is another example.

You can ask in c++std-core if you want an authoritative opinion, but I'm 
pretty certain that sequence points only impose partial ordering.

>> - I don't believe that constructors need any special treatment. In:
>>
>> struct X { int m; X( int m ): m( m ) {} };
>> struct Y { int m; };
>>
>> X x( 1 );
>> Y y = { 1 };
>> int a[1] = { 1 };
>> int b = 1;
>>
>> I see no difference between x and the other variables from
>> memory model
>> point of view.
>
> This may indeed not be an issue for us.
>
> The question here is if I have
>
> X *p = 0;
>
> and then later I execute
>
> {
>     X x(1);
>     p = &X;
> }
>
> and another threads reads a non-null p.  Is the
> x field guaranteed to be initialized?
>
> But I think the answer is that's illegal unless p
> is declared __async volatile, in which case we get
> the necessary ordering constraint from that.

Yes; my point was that the presence of a constructor does not change 
anything, we get the same visibility issue if X is an int or a POD.

> Sounds reasonable to me.  (I actually think __thread is quite
> useful without this, since you at least get __thread pointers,
> which is what I tend to use.  And unlike pthread_..._specific,
> I think they're generally faster than what I can implement myself.)
>
> I'll put it in for now.  I expect the only disagreement we
> might get is from implementors.

I can implement it in a library, so it must be possible to implement it in 
the language as well, right? ;-)