From: P.H.Welch_at_email.domain.hidden
Date: 1998-07-07 16:43:16
Dear All,
Just a note that we have released the next version (0.5) of our JCSP
library:
http://www.hensa.ac.uk/parallel/languages/java/jcsp/
We've added a PriParallel class and fixed some bugs in some of the more
exotic classes we threw into the last release at the last moment (e.g.
BlackHole channels and InfinteBuffer channels!).
We don't really know what the proper semantics for *nested* PriParallel
should be -- it was the same problem for PRI PAR on the transputer.
Ideas please?!!
We've taken the simple-local view that the components of a PriParallel
run at decreasing levels of (JVM thread) priority, with the last
component having the same priority as the invoking process. Note: as
for the transputer/KRoC implementations of PAR, the last component is
actually a continuation of the calling process.
So, the immediate components of a PriParallel run at correct relative
priorities ... but if one of them also goes PriParallel, its subcomponents
will run at higher levels than some of the higher priority bits of the
original PriParallel! Dunno what to do about that ... we really need
a tree structure for defining priority levels ... but that might carry
bad run-time overheads ... ?
The JDK 1.1 priority model is natural numbers from 1 to 10 (with 10 being
the highest). You start at priority 5. So if you want lots of prioroties
in JCSP, drop to priority 1 before going PriParallel! If your PriParallel
has more components than the JVM supports, the top components are levelled
of to the top priority. If you started in a ThreadGroup which has its
own max/min priorities, these are respected.
Cheers,
Peter.
This archive was generated by hypermail 2.1.7 on 2004-10-31 20:03:56 GMT
© Copyright WoTUG
All rights reserved