[cpp-threads] memory model

[Peter Dimov]

Comments on the proposed memory model document:

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

- the term "field" is alien to C++. C++ is specified in terms of "objects"; 
when it's necessary to distinguish between the various types of objects the 
standard uses "subobject", "array element", "nonstatic data member of a 
class" and so on. But I think that the memory model does not need to 
distinguish between the different kinds of objects.

- "mutable volatile" already has a meaning.

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

- I think that silently making "mutable volatile uint64_t" atomic on 
platform A and nonatomic on platform B is very much not in the spirit of 
making atomic operations accessible to the average programmer. I'd prefer 
"mutable volatile" to be a compile-time error ("require a diagnostic") when 
the access is not atomic.

- I believe that we must specify the interaction of the __thread storage 
duration with user-defined types, in particular constructors and 
destructors.

Existing practice simply disallows such types. This is unacceptable; it 
makes __thread (even) less useful than pthread_setspecific.

I suggest the following tentative formulation:

- In a given thread, the constructors of all variables with __thread storage 
duration are run before the first access to a variable with __thread storage 
duration (but the implementations are strongly encouraged to execute the 
constructors before the thread procedure is entered);

- The constructors are run in the same order that could have been used had 
the variables been declared with static storage duration;

- The destructors of the variables with __thread storage duration are run 
immediately after the thread procedure returns (normally or via a 
cancellation exception or pthread_exit) in the reverse order of 
construction;

- The constructor or the destructor of a variable with __thread storage 
duration shall not throw exceptions.

The above constructor rule does not cover function-scope __thread statics, 
which obey the usual "constructed when the function is first entered by a 
given thread" rule.