[cpp-threads] Somewhat relevant technical report

[Hans Boehm]

I certainly believe we are doing #2.

We haven't so far thought very much about some of Nick's major concerns,
e.g. which functions can be used to synchronize between threads, possibly
transitively through other processes.  I would prefer to address these
issues only for C++ library functions, but to provide a clean and
extensible framework that can be used for extending the spec to other APIs
such as Posix or win32 or higher level libraries.

Hans

On Sun, 18 Dec 2005, Herb Sutter wrote:

> 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
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>