[cpp-threads] Preparing for Oxford

[Nelson, Clark]

> Re #3: I know a lot of work has been put into the current C++ 
> MM proposal, but my concern is only increasing that its 
> current formulation is just too complex (and not just because 
> this month's threads have discussed increasing the number of 
> relations to 5 or 6, some primary and some secondary). In 
> Redmond and Portland, even the authors of the C++ MM proposal 
> didn't always have the same understanding of what the 
> proposal said about a given code sample. Some of this is 
> unavoidable in any complex proposal, but I worry that the 
> current complexity can be a killer for not just usability but 
> implementability. (If I had a dollar for every time I've 
> heard Hans say he's not sure if JMM implementations get a 
> given feature right, I could buy a grande latte or three.)
> 
> I would like to strongly encourage us to attempt defining the 
> MM using a single relation. If I can't convince enough people 
> of that, then I'd try to encourage at least something less 
> than 4-6+ different interacting relations. As you know, I 
> think a single relation is possible, and so far all the 
> concerns I know of that Hans raised to me about whether 
> Prism's single-relation approach works have been addressed 
> (including in some side discussions in Portland).
> 
> I don't care if the single relation is Prism's or not. I do 
> care that the MM be understandable, because that affects both 
> usability and implementability, and outside this small group 
> there's a widespread feeling that the Java MM, and anything 
> of equivalent complexity, just isn't understandable (sorry) 
> despite it many other strengths (and there are many).

Personally, I think the standard really needs to describe at least 3
relations.

The "sequenced before" relation is just a clarification of what is
currently described using sequence points. It guarantees to the
programmer what side effects are visible to what evaluations within a
single thread. And we must obviously be able to specify what happens
within a single thread in order to have any hope of specifying what
happens in a multi-threaded program. A clear understanding of what is
(and is not) required to happen in a single thread is also necessary to
understand what optimizations are (and are not) valid.

Similarly, the relation (currently) named "inter-thread ordered before"
is crucial to understanding how to control visibility of side effects by
a single thread from a different thread. Again, this information is
important both to programmers and to compiler writers.

And the "happens before" relation is effectively the definition of the
behavior (and conformance) of a multi-threaded program. I don't think
there's any way we can get away without defining that.

I'm definitely sensitive to the complexity of the description, but I
don't think eliminating any of these relations is either possible or
desirable. (The others, I think, are negotiable.)

Clark