Let's talk about thread safety ... :-)

[Roy Wilson <de...@bellatlantic.net>]

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) jfastr@bellatlantic.net
(Business) JLWIP_Services
(Affiliate) HotDispatch

>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 1/26/01, 9:15:44 PM, Brian Goetz <br...@quiotix.com> 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
> brian@quiotix.com           Tel: 650-843-1300            Fax: 
650-324-8032

> http://www.quiotix.com


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org