Re: Sun JSR 166 - Concurrency Utilities

[Doug Lea <dl@xxxxxxxxxxxxx>]

Richard,

Thanks for the comments! 

As a general reaction, JSR166 has a broad, but not deep, scope. We
provide capabilities at several levels, with several different target
audiences. For example, we don't think that the kinds of developers
using thread pools will overlap much with those using atomics. And
similarly:

> The Condition class imports some low-level POSIX threads semantics. 
> Whilst this may be appealing to people with a POSIX background, it does 
> not really offer people the safer medium-level constructs that JSR166 
> aims for. For example, 
> http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/locks/Condition.html 
> shows an example BoundedBuffer class which is not dissimilar from 
> wait/notify code in general, as illustrated by the inner workings of 
> Peter Welch's Crew class. The problem with such constructs is that they 
> take a long time to understand because one bit depends on another bit. 
> In particular, the need to have while loops shows that the constructs 
> are inadequate.

We hope that by supplying other common constructions (BlockingQueues,
CyclicBarriers, ReadWriteLocks, etc), fewer application-level
programmers will ever need to use Lock+Condition (or builtin
synchronized/wait/notify). But the developers one level under them
will still need these to build new synchronization constructs.


> * JSR166 has no equivalent to the CSP alternative. This is an important 
> omission because CSP depends on it. 

Good point, but not one for which we have a good solution.  The
details of "alt", "select", "collect" style constructions (all of
which are variants of the same idea) tend to vary too much across
different contexts for us to provide one or a few APIs. For example,
last week on the concurrency-interest list there was a discussion of
supporting "completion ports" for IO-based systems, which is usually
best implemented by collecting "completion handles" from several
sources into a single BlockingQUeue.  This works well.  But the actual
API often varies according to exactly what kind of IO you are doing.
And it is straightforward enough to program particular solutions using
other JSR166 stuff that there isn't much motivation to supply a class
what would only rarely be exactly what you want.  And both the
semantics and the implementation wouldn't usually be desirable for
supporting JCSP-style "alt".  So we will probably do nothing here.

The underlying theme is to standardize APIs at a given level only when
doing so meets practical needs; and otherwise give people better tools
one level down for creating their own customized solutions.  Decisions
about which side of this fence a given usage lies on are judgement
calls that we often argue about inside JSR166. Surely we will get a
few wrong.

> * InterruptedException is widely thrown. I am not sure whether this is a 
> good thing: although it would apparently be a practical necessity, it 
> makes reasoning about concurrency much much more difficult because it 
> introduces many more states. 

True, but developers of many real systems must introduce complexity to
achieve responsiveness and reliability. The inability to timeout or
interrupt out of an attempted lock is among the biggest complaints
about Java by "serious" infrastucture developers. Now they can do so.

>  A reasoned design is able to abort by 
> design, not by exception. This is admittedly a different mindset,

Editorializing: Merely a different mindset. I personally think
that interruption via exception is easier to design with.

> * Futures provide asynchronous method calling. On the face of it this 
> seems simple enough but I have worries that it might open a can of 
> worms. Was it a problem that Corba got into, then having to have complex 
> concurrency control to overcome the problems? Not being a Corba expert, 
> I'm not sure about this and I'd like some reassurance.

Some of the details of ThreadPoolExecutor (our main swiss-army-knife
Executor implementation) are specifically designed to regularize and
simplify construction of the kinds of middleware frameworks used in
Corba, web services, etc. They are still not usually simple though, in
part because there are so many choices about how to do concurrency
control.

> Perhaps a new java.util.concurrent.csp package 
> could subsume these?
> 
> I'd like to contribute to the details of how this is done.

If this goes anything like util.concurrent, prepare for literally
thousands of hours of work from conception to release!

> PS Should this discussion be cc'd to the 
> concurrency-interest@xxxxxxxxxxxxxxxxxxxx list?

Doing this might get some wider reaction, but logistically, it doesn't
work out very well to CC two different subscriber-only mailing lists.

-Doug