[cpp-threads] Somewhat relevant technical report

[Nick Maclaren]

> >> I agree that the lock/unlock pair prevents this transformation.
> >
> > Nope. A dummy lock can be removed entirely.
> 
> It can't unless the compiler can prove that it's not being locked anywhere 
> else. 

Er, no.  And, yes.  And, maybe.  And, both.  And, neither.  And, ....

The reason that this isn't going anywhere is that the specifications
in POSIX and C++ are seriously ambiguous, and somewhat inconsistent.
There is therefore an unlimited supply of incompatible interpretations
that can be claimed to be the One True Meaning.

POSIX does, indeed, say what causes synchronisation - but does not
say what it means by synchronisation.  I can think of at least three
'dimensions' where there are multiple different, plausible, meanings
of that.  And I have heard of at least half a dozen of the possible
combinations actually being implemented!

Furthermore, it ignores the fact that every practical 'threaded' 
program ever written has relied on temporal and other external forms
of synchronisation.  And I do mean ALL - not just Unix ones, but
everything from the 1950s onwards, in any languages.

Now we come to the language issues.  C has a bizarre and not totally
self-consistent synchronisation model that doesn't even make SENSE
in a parallel context.  POSIX leaves all language semantic issues to
C, but does not define how POSIX synchronisation interacts with that.
C (correctly) believes that it is POSIX's business to specify the
behaviour of the interactions between threads.

[ Yes, I do mean C in that, but C++ is negligibly different.  Its
synchronisation model is marginally less bizarre than C99's, but
is pretty well identical to C90's. ]

There are precisely two approaches here:

    1) To define a purely syntactic binding of C++ to POSIX, and say
that it is the user's problem to work out the memory model used by
the implementation.  People who believe in writing portable code
can get stuffed.

    2) To sit down and define a consistent memory model for C++,
which at the very least specifies which C++ external functions (e.g.
I/O and time measurement) do and do not synchronise (and how).  And
THEN add an appendix that says how POSIX fits in (if at all).

Attempting to combine these approaches WILL fail, exactly as POSIX
did when attempting to do the same with its threading and C's memory
model.


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