+1 to a separate project, a Commons Parallels perhaps. The scope of [lang] is narrower than what the vision of this new code suggests. And yes, make Java 5 or even 6 the requirement.
Gary -----Original Message----- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Saturday, January 24, 2009 10:36 AM To: Commons Developers List Subject: Re: [lang] Concurrency utils for JDK 1.5+ version 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
