Possible language changes

[Doug Lea]

>>
>>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