Let me add that Lea, and Pugh to a lesser degree, have suggested the
usefulness of CSP, especially the Java Communicating Sequential Processes
library available at
http://www.cs.ukc.ac.uk/projects/ofa/jcsp
I have just completed a somwhat trivial, and admittedly ugly,
demonstration of my own that is available (along with the main-class
source) at
http://sourceforge.net/projects/osesmp
It does involve, however, 84 processes running in parallel. Threads are
encapsulated within processes and processes communicate over channels, so
the synchonization primitive (very often) disappears.
Finally, consider the following, if you will, which appeared on the
java-threads mailing list just tonight:
------
"...I have just finished development of a driver to real time vehicle
routing and
load optimization system. This is 100% JCSP, and quite complex: about 50
CSProcesses,
and well over 200 channels (however, I have never counted them :) It took
only
about a month, a small fraction of time estimated on the basis of our
previous
efforts with other threading libraries. There was almost no debugging,
except
for fixing typos and ordinary stupidity, as well as some problems with
initial
functional design.
JCSP itself didn't create any problems (I was using only jscp.lang
package).
JCSP is ABSOLUTELY GREAT!
Most likely I will make a revision of first release: I have been using
only
"standard" CSP channels, but in seems clear that using call channels
would
simplify the design.
Regarding the functionality provided by JCSP: some support for debugging
would be useful, such as exposing (read only) some internals of Parallel
object, such as number of processes that are active, or get access to
processes maintained by Parallel. In addition, I spent quite a bit of
time
developing facilities for building and logging the "trace". It would be
good to have some pre-cooked functionality that would support getting the
trace.
Anyway, congratulations for developing great library!..."
Comment: this is not a toy problem, this is a part of 20 man/years
commercial
project.
-------
Roy
Roy Wilson
(E-mail) [EMAIL PROTECTED]
(Business) JLWIP_Services
(Affiliate) HotDispatch
>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 1/26/01, 9:15:44 PM, Brian Goetz <[EMAIL PROTECTED]> wrote regarding Re:
Thread-safety:
> >The reputation of Bill Pugh is quite high - enough so that I would be
> >nclined to take his statements on this subject as beyond challenge.
> As well you should. And many very smart people have signed his
> declaration, including Doug Lea.
> >Upon careful reading of the link mentioned in this thread, I came across
> >the following:
> >
> > It will work for 32-bit primitive values
> >
> > Although the double-checked locking idiom cannot be used for
references
> > to objects, it can work for 32-bit primitive values (e.g., int's or
> > float's). Note that it does not work for long's or double's, since
> > unsynchronized reads/writes of 64-bit primitives are not guaranteed to
> > be atomic.
> This statement is true, but very easy to misinterpret; be careful. There
> have been many attempts to "fix" DCL by trying to exploit that; they all
> fail.
> >Based on this, it would seem to me that the code snippet staring with
"if
> >(_jspx_inited == false) {" is safe. Worst case, change _jspx_inited
from
> >boolean to int.
> Seems that way, but its not. You can't use this to make an end-run
around
> the problem in the general case. If jspx_init() creates any objects,
> you've gotta synchronize, plain and simple. If jspx_init() calculates
> multiple primitive values, which can obtained through any other means
than
> its return value, you've gotta synchronize.
> --
> Brian Goetz
> Quiotix Corporation
> [EMAIL PROTECTED] Tel: 650-843-1300 Fax:
650-324-8032
> http://www.quiotix.com
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
