T_Christopher: I'm not familiar with the specifics of the University of Kent's efforts, but I strongly disapprove of Occam being a model for threading. It is based on Hoare's "Communicating Sequential Processes" and connects threads through communication channels. Although it extends to distributed memory systems easily, and prevents system crashes caused by producer threads running faster than consumers, it doesn't do very much that I like to do. I really prefer handling the stuff myself. It's easy for me, and I like the flexibility. An example from the book: I have a version of Shellsort that requires sharing an array and dynamically creating runnables to process it. The communicating process structure of Occam isn't appropriate to the algorithm.
I suspect Occam is being too strongly (mis-)associated with the
assertion that shared-memory models are wrong. The panelist apparently
holds views against occam (and JCSP) because he only uses a shared memory
model.
Earlier, the same expert had described misunderstanding or misuse of threading rather glibly:
A couple of problems are: 1. Not using threading but trying to program around it with sequential code. It tends to get messy. 2. Not handling the synchronization properly. It tends to work under light loads and then crash or freeze up unpredictably under heavy loads.
His approach does not inspire confidence that he is committed to
dealing with the problems of race, deadlock, livelock, and starvation in
a thorough way. Maybe I'll have to read his new book (http://www.sun.com/books/catalog/christopher/).
Rick
begin:vcard n:Beton;Richard tel;pager:ICQ: 56840977 tel;cell:MSN/Hotmail: richardbeton@xxxxxxxxxxx tel;fax:01794 833434 tel;work:01794 833458 x-mozilla-html:TRUE url:http://www.beton.freeserve.co.uk/ org:Roke Manor Research Limited;Internet Technology & Networks adr:;;Roke Manor: http://www.roke.co.uk/;;;SO51 0ZN;UK version:2.1 email;internet:richard.beton@xxxxxxxxxx title:Internet Consultant note;quoted-printable:The information contained in this e-mail is confidential and must =0D=0Anot be passed to any third party without permission. This =0D=0Acommunication is for information only and shall not create =0D=0Aor change any contractual relationship. =0D=0A fn:Rick Beton end:vcard