[cpp-threads] Editorial comments on the straw man

[Boehm, Hans]

> From: Nick Maclaren
> "Nelson, Clark" <clark.nelson at intel.com> wrote:
> >
> > If it turns out that "action" really needs to include only memory 
> > transactions, that presumably boils down to primitive/atomic 
> > operations, loads (which can be defined as an lvalue-to-rvalue 
> > conversion), and stores (which can be defined as an assignment, 
> > compound assignment, increment or decrement).
> 
> I am afraid that it doesn't, but I still have to persuade 
> everybody of this point!  Such things as setting and using 
> state in the library (e.g. locales) are fairly obviously 
> equivalent to hidden memory uses, but things like throwing 
> and catching exceptions aren't.
I should clearly expand on the library issues in the strawman proposal.
I think we agree that the fundamental approach there should be that
anything that logically updates state (e.g. by changing a container, or
setting a locale) should be viewed as logically storing into a location,
and correspondingly for reasing state.  By default, it is the clients
responsibility to provide synchronization to avoid the resulting data
races.  That's essentially how current implementations work.

But I'm afraid there are many special cases that deserve attention.
Posix/C I/O by default does implicit locking.  (I'm inclined to believe
this was a mistake, but it's not one we can fix.) I'm not even sure I
understand to what extent this was carried over to C++ I/O in current
implementations.  And I haven't looked at things like locales.  And we
need to clarify that memory allocation does not logically alter state.
And ...
> 
> > Also presumably, a load or store will be defined as an access to a 
> > scalar object. And the set of scalar types will probably have to be 
> > divided into two subsets: those which do guarantee atomic 
> access (or 
> > at least can, for some set of operations), and those which do not 
> > provide any guarantees of atomicity.
> 
> Yes and no.  There is a question about whether accesses to 
> non-scalars should be described in terms of multiple accesses 
> to scalars with an indeterminate ordering, or in terms of a 
> single access to a compound object.  Either approach is viable.
If we do things right, none of this should matter, except in how things
get written down.  All the formulations should be equivalent.  Only
programs with data races can tell the difference, and they have
undefined semantics.

Only the atomics library really guarantees atomicity.  (We may
eventually add syntax to avoid the library calls, but I don't think
that's fundamental.)

Hans