[cpp-threads] RE: Comments on Hans's latest strawman proposal

[Nick Maclaren]

> [Apologies that this is overly long.  I suggest that further responses
> break this up into separate threads.  In general, I'd appreciate small
> patches to the strawman proposal, so that we can discuss/incorporate
> them, especially once I finish the current revision pass.]

Sorry - my fault.

> The second clause "If A is an atomic reference ..." gives those
> constraints.  You are correct that there is not necessarily a
> happens-before ordering between atomic and ordinary references from the
> same thread; it depends on the ordering constraints associated with the
> atomic reference.

Thanks.  I misread that clause.

> > > Consistent executions
> > >
> > >   1. The actions of any particular thread (excluding values
> > >      read from potentially shared locations), and the
> > >      occurs-before relation, are consistent with the normal
> > >      sequential semantics as given in the rest of the standard.
> >
> > Gug.  That will offer plenty of scope for perverse interpretations.
>
> As we converge on the standardese, we should try to improve that. I'm
> not sure we can eliminate the problem completely, but I'm also not sure
> that it's a major practical problem.

I am afraid that it is.  In particular, the standard semantics are NOT
sequential in several respects and threading will expose many of the
ambiguities.  Sequence points are only the most obvious example.  But
I agree with your strategy for resolution.

> > >   2. The synchronizes-with relation is consistent with the
> > >      constraints imposed by the definitions of the synchronization
> > >      primitives. For example, if S is an atomic store which
> > >      synchronizes-with an atomic load L, then the loaded and
> > >      stored values must be the same.
> >
> > I don't understand what you mean by this, and whether it is
> > constraining the program, implementation or what.
> >
> It effectively constrains a consistent execution to be consistent with
> the definition of the synchronization primitives (which is unfortunately
> still TBD).  Effectively that constrains the implementation of the
> synchronization primitives.

I see.  I think that it needs clarifying.


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