commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russel Winder <russel.win...@concertant.com>
Subject Re: [lang] Concurrency utils for JDK 1.5+ version
Date Sat, 24 Jan 2009 17:30:48 GMT
On Sat, 2009-01-24 at 17:37 +0100, Oliver Heger wrote:
> Since Java 1.5 there is a lot of functionality in the area of thread 
> synchronization and multi-threaded programming. However, there are 
> certainly still missing features or APIs that could be improved or made 
> easier to use.
> 
> How about adding such features to an upcoming version of Commons Lang? 
> What I have in mind is things like the following:
> 
> * Some utility methods related to ExecutorServices, e.g. handling of 
> ExecutionException, shutting down an executor and waiting for its 
> termination, etc.
> * A generic(s) implementation of the lazy initialization pattern.
> * A caching service offering more concurrency when creating the objects 
> to be cached is expensive.
> * Maybe some specialized synchronization primitives.
> 
> Surely more points can be added to this list.
> 
> WDYT?

Hopefully the following is not deemed OT given the above.

I wonder if: a) this is a slightly misdirected direction; and b) a great
opportunity to do something really important for Java.

With increasing parallelism underneath the JVM comes increasing real
parallelism in applications.  Java has always had threads, but it was
mostly time-division multiplexing concurrency (except on "big iron").
Issues of concurrency and synchronization are generally held to be the
biggest problems in computing -- I one of those who think this.   I
think java.util.concurrent and all the work Doug Lea and others have
contributed to evolving concurrency and parallelism support in Java have
been great.  The question is whether it goes far enough.

Much of the effort in "Java concurrency" to date has been about trying
to make controlling synchronization and concurrency easier for the
average programmer.  I wonder though if this is a failure of
abstraction.  Perhaps what should be happening is that the tools we have
are used to create new abstractions to make application programming
easier in the increasingly parallel world of computer devices.

At the heart of all the problems is shared memory.  Perhaps it is worth
challenging the use of shared memory models for application programming;
perhaps it is worth building new APIs that avoid shared memory in order
to make application that exploit parallelism easier for the average
programmer to write.

I am here thinking about CSP-based models:  separate processes each with
their own memory and communicating via message passing.  C, C++ and
Fortran are all going the MPI route for multicore as well as cluster
systems (true there is also OpenMP but that is shared memory thread
control and so has some serious scaling issues).

Erlang has shown that parallel applications can be written that do not
suffer unexpected deadlock and livelock.  Also it shows that you can
build an efficient process-based system on a shared memory
multi-threaded system -- not surprising really.

So rather than trying to tinker round the edges of JSR166, JSR166y,
java.util.concurrent, might it be better to create a whole new API to
allow much easier programming of parallel applications.  This could be
done as a JSR or just done as an Apache project.

A lot of the ground work on CSP and Java has already been done by Peter
Welch and his group at University of Kent.  Also there is work being
done on dataflow APIs for Java (cf. Pervasive DataRush) -- their results
show that for certain classes of crucially important applications
dataflow is far, far more efficient than anything written using more
traditional Java application architectures.

This email has already got a bit long, and to go into more detail would
take a full document, so I will end here having raised the strategic
rather than tactical issue.

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

Mime
View raw message