Document of relevance

[Kevlin Henney]

In message 
<65953E8166311641A685BDF71D865826058C54 at cacexc12.americas.cpqcorp.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
____________________________________________________________