|
>>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. Kevin Chalmers Research Student 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. |