[cpp-threads] Somewhat relevant technical report

[Nick Maclaren]

"Boehm, Hans" <hans.boehm at hp.com> wrote:
> 
> My goal is to have the foundations worked out by the Berlin meeting, and
> hopefully to have some confidence that they are correct this time
> around.  I would also like to have a better draft of the atomic
> operations interface by then.

Please remind me - when is that?

> In working towards the standardese, I think I would be inclined to
> replace any mention of "sequence point" with some other term like
> "occurs before".  As I mentioned on the reflector, sequence points are
> really used to describe an ordering, which is confusing.  And IIRC,
> Clark Nelson pointer out that sequence points aren't used consistently
> in the standard anyway.  In my mind, it makes no sense to me to try to
> build an easily understandable thread semantics on a needlessly
> confusing sequential semantics.  We don't want to lose readers before
> they even get to the interesting part.

PLEASE stay away from sequence points!  At best, they describe a
partial ordering in terms of a unspecified complete ordering of the
nodes of a tree.  Several people have been trying to get the mess
improved in the C standard, and have had major problems.  Clark
Nelson is right, too, and your summary is correct :-(

> Do you think this would fly in the committee, or is there enough history
> here that we shouldn't touch sequence points?

If you try to use sequence points, you WILL fail.  I think that a
sane specification could be written that sidesteps them.   But, of
course, they have to be mentioned :-(  I don't know the politics.

> My reading is that the reflector discussion about fixing argument
> evaluation order is not likely to go anywhere, and we should ignore it,
> at least for now?  (I'm not suggesting that it shouldn't go anywhere,
> only that it didn't seem to.)

My view is that it could be thrown in with the sequence point mess,
in the following way:

    Call all objects that are accessed in all statements that are
active when a synchronisation function is called, a "morass".  Also
use it to refer to the hierarchy of statements.

    The memory model defines the semantics of all objects that are
not in the morass of any of the relevant synchronisation functions.

    The memory model states that, for any statement in the morass,
any object access that is required to be completed before (or not
started until after) the call of the synchronisation function by
the serial semantics is deemed to be in a previous (subsequent)
statement as far as the memory model is concerned.

    If there are any object access then left in the morass, nothing
is expressed or implied about their serialisation by the call to
that synchronisation function.


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