Possible language changes

[Boehm, Hans]

I agree with Doug.  But I think it would be much harder still to
standardize the higher layers in C++, since we have such a diverse
set of existing interfaces, some of which are very heavily used:

1) Pthreads, Boots, NSPR, ..., which seem to use roughly similar threads
models, and could perhaps be unified.  (The Ada and Java models also
seem pretty close, though obviously different enough to generate
heated debates.)

2) The original Windows event model, which I have never understood how
to use correctly, but is probably still quite popular.

3) OpenMP which I think is fairly heavily used by a smaller community,
and I think has similar memory model issues, but a completely different
(and successful in its domain) programming model based mostly on barrier
synchronization.  UPC probably also fits in here, though I'm not an
expert.  I don't think that users of these systems are 
interested in a layer like those in (1) or in an Ada-like model,
though they might want to interoperate with it.

4) uC++, which adds coroutines into the mix, among other things.

5) Nonpreemptive thread libraries like GNU Pth.  I don't much like this
as
a general purpose approach, but it also seems to have its niches, and
certainly followers.  Although hardware reordering is not an issue,
the compiler still needs to respect a memory model.

...

Hans

> -----Original Message-----
> From: Doug Lea [mailto:dl at cs.oswego.edu] 
> Sent: Wednesday, March 02, 2005 6:00 AM
> To: jimmaureenrogers at att.net
> Cc: Doug Lea; Boehm, Hans; Ben Hutchings; Andrei 
> Alexandrescu; Kevlin Henney; Bill Pugh; Douglas C. Schmidt; 
> Maged Michael; asharji at plg.uwaterloo.ca; Richard Bilson
> Subject: Re: Possible language changes
> 
> 
> 
> >>
> >>Can anyone make a good case for doing more ethan this?
> > 
> > 
> > Of course we can.
> > History tells us that low level constructs such as these will 
> > eventually generate a number of libraries to implement higher
> > level concurrency abstractions. 
> > 
> > Eventually C++ will need to develop a concurrency equivalent to the 
> > STL; a standardized Threading Library. Why suffer the 
> > incompatibilities of many libraries followed by an eventual 
> > standardization? This would only repeat C++ history that 
> does not need 
> > to be repeated.
> > 
> > There are already several threading libraries available for C++. 
> > Implementation of low level concurrency abstractions will 
> simply cause 
> > more threading libraries to be created.
> > 
> > Is it really necessary to define a perfect threading approach for
> > C++, or is it sufficient to define a very good threading approach?
> > I believe that a very good approach is achievable and 
> useable within a 
> > reasonable time frame. Perfection will never be achieved.
> > 
> 
> I'll shut up about all this soon, since my opinion about 
> these things shouldn't even count because I hardly ever write 
> concurrent
> C++ programs any more (instead Java and C).
> 
> But here's the parallel story about Java, that might help 
> explain my suggested plan of attack.
> 
> 1. Java initially had simple concurrency support that most 
> people thought was better than anything in any other 
> production language. (You all by definition are not in that 
> "most people" set :-)
> 
> 2. So people started doing all sorts of fancy things with
> Java concurrency (like making big server middleware 
> frameworks) and found many cases where they couldn't get the 
> effects they wanted or got crummy performance, or had to keep 
> reinventing error-prone constructions because they had to 
> base things off what Java offered rather than what was possible.
> 
> 3. So people built libraries to cleverly get most of the 
> lacking expressiveness (but not the performance). (By chance, 
> the world standardized on the packages I wrote.)
> 
> 4. Eventually (J2SE5), intrinsic support was put in to 
> provide the underlying missing capabilities (like atomics, 
> better blocking primitives, new JMM rules), and an efficient 
> and extensible support package (java.util.concurrent) was put 
> into the platform. Most people can and do still rely on the 
> original basic support for simple concurrent programs, but 
> gravitate to j.u.c as soon as they do anythign even 
> moderately interesting. The j.u.c package is completely 
> agnostic about the "best" way to write concurrent programs. 
> It includes support for all sorts of styles.
> 
> 5. The existence of a standardized package allows controlled 
> evolution. For example, we just integrated some new 
> non-blocking collections that will go into J2SE6. But we also 
> leave a lot of things out that are useful but only to small 
> sets of developers.
> 
> 6. We are starting to see people put together the
> next layers. For example concurrency packages that extend
> j.u.c for enterprise apps, with Executors that remember 
> transaction contexts. And more complete high-performance 
> parallel processing packages, with fancier tree-barriers. And 
> so on. We were careful to set up j.u.c so that such 
> extensions run just about as efficiently as if they were 
> built-in. (See for example my paper on the synchronizer 
> framework http://gee.cs.oswego.edu/dl/papers/aqs.pdf)
> It is not at all easy to actually make them that fast, but 
> libraries tend to be written by experts who are willing to 
> work hard at it.
> 
> My main biases stemming from all this are:
> 
> 1. Keep the basic support small and simple yet extensible.
> 2. Minimize effects on programming style. There are many wonderful
>     concurrent programs written using just about every approach
>     you can name. So don't make any of them impossible or
>     unnecessarily slow.
> 3. Welcome the existence of libraries, and plan to standardize
>     those that become defacto standards.
> 
> 
> 
> -Doug
> 
> 
>