I guess I understand the thinking here, but not within the context of
commons lang. It sounds like you might want to start a new sandbox
project for this.
However, if I was doing this I would look for ways to abstract things
so that what the application programmers deal with are very abstract
and whether the implementation relies on multithreading or multiple
processes is a configuration choice. While multithreading has its
challenges, there are many cases where it is the better way to do
things. On the hand, I can imagine use cases where it would be pretty
cool to have multiple JVMs in a cluster delivering services without
the progammer having to worry about making all that infrastructure work.
On Jan 24, 2009, at 9:30 AM, Russel Winder wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
