[cpp-threads] New strawman proposal

[Boehm, Hans]

Comments interspersed.

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Doug Lea
> Sent: Wednesday, June 08, 2005 5:45 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] New strawman proposal
> 
> 
> 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?
I added a comment to that effect, rephrased to reflect my
understanding that sequence points are not ordered; they
impose order on subexpressions.
> 
> 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.
Do you have an example in mind here?

Actually, my intent was that a cycle generally reflects
an infeasible synchronizes-with relation.  I think we're not
outlawing

Initially x = y = 0, x and y are unordered synchronization
variables:

Thread 1			Thread 2
x = y				y = x

Outcome: x = y = 42
> 
> 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?
Is someone working on the atomic operations library interface,
so we know what the rows and columns are likely to be?

I'd like to see a prototype of at least the interface.
(If we had a candidate interface, I'd be interested in trying
to implement it in terms of atomic_ops, updating that
if necessary.  That should give us a semi-portable
prototype.)

Hans