Document of relevance

Wed Jan 26 21:53:55 GMT 2005

I think the two of us are basically in agreement.  If we can start a
separate effort to standardize basic thread services, such that
we can agree on them in a finite amount of time, and they contribute
more than just the (N+1)st alternative threading interface, that would
be great.  But the effort to make C++ safe for concurrency shouldn't
depend on it. 

I actually don't have a good overview of how frequently various threading
interfaces are really used.  My impression is that the most commonly
used ones are probably bare win32 threading and bare pthreads, with
Boost perhaps the most common of the C++-specific interfaces.  (My only
real data point here are request/complaints about GC support for these
things.  There have been many discussion about pthread and win32 thread
support.  I don't recall any about interaction with the higher level
interfaces.  But that's of course a completely bogus way to evaluate
this.)

I'm also concerned that we already have many conflicting views on
thread services represented here.  And Microsoft's position(s) is/are not
represented here, but probably critical.

Reflecting on my last message, I think the memory
model and atomic operations are less separable than in Java, especially
if we decide to essentially forbid races involving conventional assignments.

I agree that there a number of other C++-specific details we need to address,
once we get the fundamentals of the memory model down.

I unfortunately know nothing about the C++/pthreads binding effort.

Hans

> -----Original Message-----
> From: Kevlin Henney [mailto:kevlin at curbralan.com]
> Sent: Tuesday, January 25, 2005 7:32 AM
> To: Boehm, Hans
> Cc: Peter A. Buhr; andrei at metalanguage.com; dl at cs.oswego.edu;
> magedm at us.ibm.com; ben at decadentplace.org.uk; dl at altair.cs.oswego.edu;
> pugh at cs.umd.edu
> Subject: Re: Document of relevance
> 
> 
> In message 
> <65953E8166311641A685BDF71D865826058C54 at cacexc12.americas.cpqc
> orp.net>, 
> "Boehm, Hans" <hans.boehm at hp.com> writes
> >
> >Here's where I think we should be going:
> >
> >I think our main goal should be to make C++ safe for
> >concurrency.  In order to do this, we need to pin down a memory
> >model.  This is clearly necessary for C++ (see below).
> >Based on a quick scan of some of the documents on Peter's
> >web site, my impression is that it is also necessary for uC++,
> >for basically the same reasons.
> >
> >I would like to avoid spending time on the design of concurrency
> >facilities themselves.
> 
> Although I my focus is that of a library designer, in part I 
> agree with 
> this clearly scoped approach. However, I would not consider it 
> unreasonable to pursue a layered approach. We can categorise 
> the memory 
> model and other changes to the basic C++ execution model as level 0, 
> synchronisation and thread-execution low-level services as 
> level 1, and 
> higher-level facilities as layer 2. This is in line with the library 
> model that I posted last year, but in discussing it with Herb 
> Sutter at 
> OOPSLA we both ended up referring to them by numbers.
> 
> It makes sense to concentrate more effort on level 0 than the others 
> because this is the bit that comes back to bite. It has taken Java 
> nearly a decade to complete level 0 (and add some 
> standardised level 2), 
> with most of its early emphasis on level 1. C, by virtue of Win32 and 
> Posix, has its emphasis on level 1, but level 0 is where the 
> trouble is, 
> and ditto for C++, which has more in level 1 by virtue of various 
> wrapper libraries, such as Boost.
> 
> >My reasons for that are:
> >
> >1) This part of the design is likely to be extremely controversial.
> >If we were to couple it with the memory model effort, it would take
> >far too long for any of this to make progress.
> 
> Agreed. The two should not be coupled to one another, but it 
> would not 
> be unreasonable for a library effort to be coupled to a memory and 
> execution model effort.
> 
> >2) There exist zillions of lines of C++ code that use either
> >pthreads or the win32 threads interfaces.  And there are probably
> >only slightly fewer lines of code out there that use one of several
> >other thread libraries, such as the Boost one, or language extensions
> >such as uC++ or OpenMP.  I suspect
> >we'll get a lot further by asking all these existing users to make
> >a few small tweaks to get rid of their existing intermittent 
> bugs than
> >by telling them to rewrite their code.  And there is plenty 
> of evidence
> >that one size doesn't fit all here.  You won't get may OpenMP users
> >to switch to uC++.
> 
> OTOH, the needless (as opposed to useful) diversity is one of the 
> frustrations and causes of the millions of lines of code. It 
> is one of 
> the things that people look to a standard for, and its absence from a 
> standard is often considered a weakness and not a strength.
> 
> >3) Posix is an existing IEEE/OpenGroup/ISO standard.  I don't think
> >we should just ignore it.  (I do think it has problems.  But I think
> >they can be solved without breaking most of the code that uses it.
> >At least not any more than it already is.  And its strengths and
> >weaknesses are probably better understood than any other threading
> >primitives.)
> 
> Does anyone know the current state of a C++ binding to Posix? 
> Every time 
> I hear any discussion about it, it seems to get hung up on 
> the issue of 
> cancellation.
> 
> >4) I also don't believe that you can add concurrency to a
> >language purely with a thread library, though for somewhat different
> >reasons than what is stated in Peter's 1995 paper.
> >(See http://lib.hpl.hp.com/techpubs/2004/HPL-2004-209.html .)
> >But I do think it is possible to
> >define a memory model sufficiently abstractly that it applies to
> >multiple different sets of concurrency primitives.  The Java
> >memory model barely talks about the actual concurrency primitives.
> >(The supplier of the concurrency primitives will have to fill
> >in a few details, e.g. which pairs of operations introduce a
> >"happens-before" ordering in the Java terminology.  But I think
> >we can leave that separate from the core memory model.)
> >
> >I think a second goal of this group is to pin down a set of
> >atomic memory access and ordering primitives.  Those again appear
> >to be independent of the actual concurrency primitives.  (I've been
> >spending some time (with some help from Michael, among others) on an
> >implementation of a corresponding C package, which I hope can be used
> >to implement C++ prototypes.  I expect the interfaces to be quite
> >different, but most of the underlying implementation should be the
> >same.
> >
> >I certainly have no objection to some of us working on a better
> >thread of threading primitives for C++.  I'm sure the interaction
> >would help to keep those of us working on the memory model honest.
> >But I think we should separate that from the above two issues.
> >And it's not where my primary interest lies.
> 
> If we define level 0 as the minimum, and level 1 as something for 
> speculation or a later date, we still have to address a 
> number of other 
> issues in addition to the existing memory model. The C++ 
> execution model 
> has a number of other things that would also need to be 
> addressed, such 
> as exceptions, library re-entrancy, circumstances under which 
> a program 
> may terminate. There was some discussion of these on the BSI C++ 
> reflector a few months ago, with the general consensus being 
> for a more 
> conservative than inventive approach.
> 
> Kevlin
> -- 
> ____________________________________________________________
> 
>    Kevlin Henney                   phone:  +44 117 942 2990
>    mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
>    http://www.curbralan.com        fax:    +44 870 052 2289
>    Curbralan: Consultancy + Training + Development + Review
> ____________________________________________________________
> 