commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [lang] Concurrency utils for JDK 1.5+ version
Date Sun, 25 Jan 2009 16:15:49 GMT
The suggestion of Russel goes far beyond what I had originally imagined 
(and also beyond my expertise). This is surely out of scope for [lang].

My intension was to start with something smaller, which would certainly 
not be revolutionary, but could somewhat simplify the life of users of 
the java.util.concurrent package. IMO this would fit into [lang]: a 
small set of classes enhancing the functionality of JDK classes.

BTW: There was already a branch of [lang] for Java 1.5, but it was 
removed again. Did nothing interesting happen on this branch?


Gary Gregory schrieb:
> +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 [] 
> 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:

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

View raw message