[kepler-dev] concurrency libraries for jdk 1.4

[Edward A. Lee]

The two are addressing the same problems, but in very different ways.
One of the things I'm interested in determining is whether the rendezvous
domain can be effectively and efficiently used for such problems.
This has not been proven...

One of the motivations for this is that I have concluded that nontrivial
multithreaded Java programs are incomprehensible and cannot be made reliable.
One of my favorite illustrations of this is the CrossRefList class in
the kernel of Ptolemy II... It is responsible for ensuring consistent
representations of a Ptolemy II model when multiple threads are modifying
the model structure. It was carefully designed, then design reviewed for
concurrency bugs, then code reviewed to "green." It has tests in the
automated regression tests that run nightly, and the code coverage stats
show 100% code coverage.  And it ran for four years (2000-2004) before it
deadlocked during a demo...  The fix was extremely difficult, and relies
on properties of the Worskpace class and on a stylized usage style. So
the fix is brittle...

I think that PN and Rendezvous domain models are much easier to understand
than multithreaded Java programs.  The question is whether they can be made
as expressive...

Edward



At 09:44 PM 11/15/2005 -0600, Kevin Ruland wrote:

>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
>

------------
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