[cpp-threads] Memory model counterproposal: synchronized operations

[Nelson, Clark]

One of the problems with the current proposal is that it doesn't have an
explicit category of accesses that aren't constrained by
synchronization. Taken at face value, it's not clear that this isn't
intended to override the as-if rule, and therefore it isn't clear that
any optimizations are still allowed. So I conclude this must be an
oversight -- a fairly serious one.

I would propose to fill in the gap by saying explicitly that accesses to
objects with automatic storage duration (i.e. non-static locals) are not
subject to synchronization, and therefore autos can not be used
(portably, reliably) to communicate between threads. On the other hand,
accesses to objects with static or dynamic/allocated storage duration
are subject to synchronization, and such objects can be used for
inter-thread communication.

This specific distinction is analogous to existing standard
distinctions:

In the Java memory model, "it is impossible for one thread to access
parameters or local variables of another thread."

In C and C++, assignments to (non-volatile) auto objects are not
required to "work right" in a function that invokes setjmp.

And besides, "everyone knows" that a thread has to have its own stack.

It should be noted that this formulation would not allow an auto object
to be used for inter-thread communication even by taking its address.
That is intentional. Part of the reason is that I don't particularly
want to try to draft standardese to allow it. :-)

Another part is that the address would in any event have to be
communicated between threads somehow, and the use of some static object
is the most plausible way to do it; if you have to use a static object
anyway to get started, what advantage is gained by using the auto object
pointed to by the shared static?

It should also be noted that, even if the standard declares this
practice to be not strictly conforming (i.e. non-portable), that would
not by itself break any existing programs that happen to use it. Such
programs are not supported by a standard, they're supported by an
implementation, and implementations will be free to continue to support
it as an extension.

-- 
Clark Nelson		Vice chair, J16 (ANSI C++ standard committee)
Intel Corporation
clark.nelson at intel.com