[cpp-threads] C++ committee meeting in Mont Tremblant

[Kevlin Henney]

In message <434B3320.3080709 at metalanguage.com>, Andrei Alexandrescu 
<andrei at metalanguage.com> writes
>I think that's a great outcome, Hans, and I'd like to congratulate you
>for so graciously taking ownership of this important project.

Ditto.

>I believe that the important tasks lying ahead are:
>
>1. Define the memory model
>
>2. Establish the atomic operations interface
>
>3. Develop the low- and mid-level API
>
>4. Leave room for future things (such as machine-wide atomic sections)?

Yup, this looks good.

>If (3) is modeled after Boost, I am worried that it will be quite
>clunky. Sigh. Kevlin, Kevlin, where are you. Then, I'm not sure why the
>low-level API would be necessary it the mid-level API is well-designed
>(which implies it doesn't introduce inefficiencies or awkwardnesses that
>would force one to go down to unprotected C-style APIs).

The feedback that I'm getting is that there is some interest in the 
stuff I've proposed, but that Boost currently has a bit more mindshare, 
and there is encouragement to flesh both out in more detail. There are a 
couple of on the UK panel that have expressed interest in taking this 
further, so we are likely to try and organise something to do this. I'll 
let you know more when I know more.

However, one point that Hans mentioned was the idea of standardising a C 
API, eg POSIX, out of the box. On these different approaches, let me 
repost and adapt something that I just posted to the UK reflector:

There appear to be basically three general approaches to introducing 
threading facilities into C++ that are on the table at the moment (this 
is separate from the consideration of the memory model related work):

(1) Rebadge the C binding of pthreads or something very C and very 
similar to it.

(2) Present threading to the programmer as a C++ library. This is where 
the Boost proposal and my proposal currently fit. Different as they are, 
they have more in common at this level than not.

(3) Extend the language with new concepts and syntax. This is where 
Lawrence Crowl's ideas fit (and likewise, those not on the table: Peter 
Buhr's work, Concurrent C++, etc).

The common strength of (1) and (3) is that neither is necessarily
C++-specific, albeit for quite different reasons. If C compatibility is
important, this becomes a deciding factor that pretty much excludes (2), 
unless (2) is seen as a wrapper for (1) (cf <stdio.h> and <iostream> 
relationship). By being lowest common denominator and already out there,
(1) obviously has some kind of appeal. But from a C++ (or even C) 
programming I can't say that the appeal is particularly great :->

OTOH, (3) offers a common way to extend both C and C++ in a way that 
could be considered neutral to both languages. However, politically and 
practically this is more like a marathon steeplechase than the usual 
standards obstacle course. There is no point in second guessing what the 
C committee would be prepared to standardise without also involving 
them, which introduces more cycles into the whole process. I would 
expect this process, even if successful, to be too lengthy to fit into 
the current C++ standardisation schedule. The inclusion of what is 
effectively a new type system is likely to be seen as too much of a 
disturbance on the core language.

There is of course the deeper question of whether any kind of C 
compatibility is genuinely important. Although C99 has not actually 
killed off C, it has made many people realise how much nicer a language 
it was in its previous incarnations. C is not dying, but I don't see C99 
as giving it a boost of life. How much more successful would a successor 
to C99 be, even if it included threading? My guess is that it wouldn't 
make as great a deal of difference in practice as it might in theory. So 
I am inclined to think that maybe a C-compatible approach is more 
something that sounds nice than something that is genuinely needed or 
will actually make a difference. Given that, I suggest that a C++ 
approach should focus primarily on C++ and not try to carry around any 
more baggage than needed (it is already weighed down with quite enough 
:->).

So, leaving C compatibility to one side still leaves (1) but also admits
(2). In some ways, (1) is simpler, but it would need someone to champion
it. It is certainly not ambitious, but it would get something that went
by the name of a thread library into the standard. However, I suspect 
that it would leave a bad taste in the mouths of many.

When it comes to (2) we can then enter a debate as to library style -- 
Boost vs an executor-futures based approach -- but either way it is 
understanding what would be most likely to be a sufficiently good 
design, acceptable to the committee, embraced by programmers, etc. If 
(1) or (3) is what is wanted, then there is little point in wasting time 
on (2). However, I don't really believe that (1) or (3) is what is 
really wanted or expected.

Does anyone have any strong (or weak) views on these points?

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
____________________________________________________________