>>I'd be interested to hear from JCSP people on this -- is the implementation clean, or does it have similar problems described above?
Depends what you mean by clean. You can get hold of the source code from www.jcsp.org and take a look at it and see. As an example, the One2OneChannel only has one monitor lock so is fairly clean, whereas the Alternative is a bit messier. This is not really a problem with the design of JCSP, but Java’s shortcomings. The problem with Alternative has something to do with timers in Java returning early, you’d have to check with someone more in the know on the specifics.
The performance is fairly reasonable on a decent machine, considering the benefits of portability and mobility that you get. It’s by no means up KRoC, C++CSP, or the Transterpreter speeds however. It may actually be a time to re-examine JCSP and see if it can be improved considering how far Java has gone in that time. Maybe some of the known issues have been addressed?
Brinch Hansen wrote an article about Java’s parallelism back in 1999, so you might get some idea as to Java’s problems from that. The reference is: Hansen, P. B. 1999. Java's insecure parallelism. SIGPLAN Notices 34, 4 (Apr. 1999), 38-45. DOI= http://doi.acm.org/10.1145/312009.312034.
On the topic of .NET multi-threading, I’m very disappointed by the implementation. On simple tests, Java and .NET seem to be pretty much equal, but the more threads you start in .NET, the more resource hungry it gets. I’m estimating that a running thread in .NET needs about 1 Megabyte of memory, hardly lightweight. This gives you around a maximum of around 2000 threads in a Windows XP 32-Bit machine. I doubt an OO program with only 2000 objects is desirable in this respect.
School of Computing
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the
University's system is subject to routine monitoring and filtering by the University.