[cpp-threads] Somewhat relevant technical report

[Herb Sutter]

I am far less expert in this area than Nick and you all, but my
understanding of this is exactly as Nick says with #1 and #2 and I echo
his (apparently?) strong preference for #2. Actually, I was already
under the impression that #2 was what this group was doing. :-)

Herb


> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk [mailto:cpp-threads-
> bounces at decadentplace.org.uk] On Behalf Of Nick Maclaren
> Sent: Sunday, December 18, 2005 4:11 AM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Somewhat relevant technical report
> 
> > >> 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
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads