[cpp-threads] New strawman proposal

[Doug Lea]

Boehm, Hans wrote:
> I partially updated the strawman proposal accessible from
> 
> http://www.hpl.hp.com/personal/Hans_Boehm/c++mm
> 


This looks good. Assuming we don't discover any fatal flaws,
the basic approach might be the best we can do.

Notes:

1. In :

> Given a candidate execution, and a synchronizes with relation, we define a happens-before relation on the actions in the execution as the transitive closure of the union of the following relations:
> 
>    1. The "synchronizes-with" relation on acquire and release operations. R is related to A iff R synchronizes-with A.
>    2. The intra-thread execution ordering from the candidate execution. A is related to B iff B follows A in the execution if a single thread. 

Can we replace (2) with just

   2. An intra-thread ordering in which the sequence point of A
      is prior to the sequence point of B.

   (Or some better wording.)

If so, can we claim that this is all that "sequence point"
means, and not refer to it otherwise?

2. Leaving the semantics of anything with cycles undefined
might be the best we can do, but means that many programs
will unknowingly be ill-formed. I suppose it is possible
to create tools that can detect and inform programmers about
such constructions.

3. The first test of the approach will be to create tables
of synchronizing operations that define the relations.
Offhand, it seems necessary to do this as a full N X N
table, where N is the number of synchronizing operations
(plus rows/cols for non-synchronizing ones?). Maybe the
advocates of 16-fold atomic operations would like to
try to create such tables and see if they come out sensibly?

4. (First, Off the main topic here.)
If the case of double-checked lazy
initialization of statics can be handled reasonably using
protected function-local statics, I guess I'm content to
see "__async volatile" go away. There are still many
other uses of double-check/test-and-test-and-set idioms,
all of which would now require use of atomics library,
which I suppose is OK. Although it bothers me that
it might encourage people to use more statics (because they
ae easier) in concurrent programs, which is
not something you want to encourage. But this isn't a good
enough reason to keep the qulaifiers.

(But back to main topic:) Note that we will need ad-hoc
synchronizes-with rules for accessses to protected function-local
statics.


-Doug