[kepler-dev] concurrency libraries for jdk 1.4

[Kevin Ruland]

Edward,

I am not certain if these two things (java.util.concurrent and the 
rendezvous domain) are solving the same problems.  Internally in kepler 
we have some services - such as the object manager/cache - which must be 
thread safe.  In addition, there are certain long running background 
tasks such as data queries which are executed in seperate threads.  
These functions are actually executed outside of the domain controlling 
the workflow.

Perhaps I am not understanding the possibilities.

Kevin

Edward A. Lee wrote:

>
> Possibly of interest:  Thomas Feng, Yang Zhao and I have checked
> in to the CVS tree a new domain, called "rendezvous", that uses
> extensions of CSP to get multithreaded programs that communicate
> by rendezvous. It has a small library of actors supporting conditional
> rendezvous, barrier synchronization, and buffering. All ordinary
> Ptolemy II actors should work fine with the RendezvousDirector.
>
> Together with the PNDirector, I'm guessing that these two provide
> the capabilities you would get from a thread library, but at
> a better level of granularity and abstraction.  But I would be
> interesting in hearing opinions to the contrary (or better, examples
> of things that become hard to do).
>
> Edward
>
>
> At 08:35 AM 11/15/2005 -0600, Kevin Ruland wrote:
>
>> Hi all.
>>
>> Yesterday I suggested we try to utilize a concurrency library within
>> Kepler.  This will help us reduce the volume of thread critical code
>> which we need to write and hopefully provide us with more threading
>> primitives than provided by the jdk itself (which is almost none).
>> There are two libraries which I've dug up which could satisfy this need.
>>
>> Doug Lea's util.concurrent package
>> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html 
>>
>> .  This is the basis of the concurrency library introduced in Java 5.
>> He notes that this package has been reduced to maintenance fixes only
>> because it has been superceded by Java 5.  He also refers us to the
>> second package...
>>
>> Backport of Java 5 concurrency library to Java 1.4.
>> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html 
>>
>> This library does appear to have some offical sanctions by the JSR 166
>> Expert Group (the jsr which introduced java.util.concurrent  into java
>> 5) which is a good sign.  It should also ease a transition to true java
>> 5 at some time in the future.
>>
>> Kevin
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
> ------------
> Edward A. Lee
> Professor, Chair of the EE Division, Associate Chair of EECS
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal