[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.
Regards,
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.