[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sun JSR 166 - Concurrency Utilities

Doug Lea wrote:

I'm sure there IS interest (as evidenced by the existence of
java-threads list), but none of it has led to anyone pushing for any
particular constructs in JSR166 beyond those things (like
SynchronousChannels) that are already present in current specs.
JSR166 vows to be agnostic about concurrent programming methodology,
and tries to include capabilities that will improve all sorts of
styles and approaches. So, we do not propose to standardize JCSP or
CTJ packages, but we do include things that may be of use in
constructing future versions of such frameworks.

I'm pleased that there is an opportunity to review JSR166 and perhaps propose changes. I note that the Close of Public Review is 6th December (as per http://jcp.org/en/jsr/detail?id=166). Please forgive me for wading in with a load of bold comments below: I intend to offer a constructive review.

Whilst I understand the desire to be agnostic about concurrent programming methodology, there are some issues with this. In particular, I am acquainted with some of the theoretical work that underpins JCSP, performed using CSP (this work has been documented in recent CPA200x conferences). The spin-off of this is obvious: JCSP provides a reliable set of lower level utilities to provide functionality commonly needed in concurrent programs. Conversely, JSR166 stated aim is to propose a set of medium-level utilities to provide functionality commonly needed in concurrent programs. If I am interested in building upon a theoretical foundation, I would want to build upon JCSP. This gives me a problem with JSR166 because I therefore don't know how it fits in.

In the current JSR166 API (http://gee.cs.oswego.edu/dl/concurrent/dist/docs/index.html), there are several aspects.

* There are some excellent atomic variable classes. (JCSP does not address this area.)

* There are some excellent concurrent collection classes. (JCSP does not address this area.)

* There is a locks package that contains Lock/ReentrantLock (an exclusive read/exclusive write lock) and ReadWriteLock/ReentrantReadWriteLock (a concurrent read/exclusive write lock). The latter is quite similar to the JCSP Crew class, which Peter Welch described in gory detail a few years ago (in a memorable two-projector lecture that took an hour to describe about 40 lines of code - and still left some people unsure they really understood what was going on - such things have immensely complicated dynamics. I digress). Locks are helpful, I have found, but there is always some risk of not balancing the acquires and releases, with variously adverse consequences.

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

* There is a Queue interface and BlockingQueue subinterface and a suite of different implementing classes. These are like JCSP channels, except that JCSP has greater clarity: each queue is formed from a channel with plugged-in buffering (LIFO stacks are not provided but could be).

* JSR166 has no equivalent to the CSP alternative. This is an important omission because CSP depends on it. The JCSP alternative uses the same optimisation as in the occam language, namely that the alternative construct does not support output guards, only input guards, timers and 'skip' guards (this is to avoid needing multi-stage negotiation).

* 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. A reasoned design is able to abort by design, not by exception. This is admittedly a different mindset, and underpins the difference between the CSProcess and the Thread classes. I don't know how this might be resolved: maybe others would comment.

* CyclicBarrier and CountDownLatch have no direct CSP/JCSP equivalent but are interesting because the occam community has also developed similar higher-level synchronisation primitives.

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

So in summary, JCSP and JSR166 overlap. They could in principle be merged and I, as an outsider to both, would enthusiastically support that (assuming that the owners of the JCSP intellectual property are interested). Of particular value to JSR166 would be infeed from jcsp.lang.*, jcsp.util.* and jcsp.util.ints.* (the other JCSP packages being less fundamental). Perhaps a new java.util.concurrent.csp package could subsume these?

I'd like to contribute to the details of how this is done.

Rick :-)

PS I am not very familiar with CTJ so I have not commented on it here. Please would CTJ proponents forgive my ignorance.

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

Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.