[cpp-threads] Editorial comments on the straw man

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

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

> The terms "occurs before" and "happens before", and the way they are
> mapped to the concepts they represent, appear (from my perspective) to
> have been pulled out of a hat. Given that you're effectively trying to
> replace the term "sequence point", for the intra-thread concept I'd
> suggest the term "sequenced"; for example, in the expression (A, B),
> every evaluation and side effect of A is sequenced before every
> evaluation and side effect of B. For the inter-thread concept, how about
> something like "observably sequenced", or even "inter-thread sequenced"?

Unfortunately, the current term "sequence point" is completely broken,
and there are several groups who believe vehemently in incompatible
interpretations.  Even worse, many of those groups haven't thought the
problem through and don't realise what they have assumed :-(

In my view, avoiding any confusing with that mess seems a good idea. 


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679