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
signature.asc
Description: This is a digitally signed message part
