commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [lang] Concurrency utils for JDK 1.5+ version
Date Sat, 24 Jan 2009 22:29:01 GMT
+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.


-----Original Message-----
From: Ralph Goers [] 
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:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message