RE: Java Live | January 9, 2001

[Lawrence Dickson <tjoccam@xxxxxxxxxxxxx>]

Gerald,
   I particularly fix on your statement, "maybe we should write
[a book] for the non-specialists!"
   Such a book should include rules for hand-coding that is
equivalent to real occam or CSP, and descriptions of how the
standard languages booby-trap you. The goal of truly 
independent modules that communicate without side effects 
should attract a lot of battered and bruised programmers...
who probably don't believe it is possible at all.
   Larry Dickson

>From owner-java-threads-out@xxxxxxxxx Tue Jan 23 15:03:55 2001
Reply-To: <g.h.hilderink@xxxxxxxxxxxxx>
From: "Gerald H. Hilderink" <g.h.hilderink@xxxxxxxxxxxxx>
To: "Java Threads mail group" <java-threads@xxxxxxxxx>
Cc: "Andre Bakkers" <bakkers@xxxxxxxxxxx>
Subject: RE: Java Live | January 9, 2001
Date: Tue, 23 Jan 2001 23:53:56 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3A6DB53F.702865A1@xxxxxxxxxx>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIME-Autoconverted: from 8bit to quoted-printable by utep.el.utwente.nl id XAA16817
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by crash.cts.com id f0NN3t191164

Thanks Rick,

This T_Christopher seems to be a specialist in programming concurrent
software. He is probably one of a few specialists in the world. I am almost
certain that he uses certain design patterns using the multithreading stuff.
It is likely that channel like patterns are among them.
He is not familiar with the CSP/occam stuff because he does not realize the
strength of channels combined with compositional programming AND combined
with semaphores (Peter Welch?s addition to occam) to build his algorithm. He
uses the word ?flexibility? and this sounds like a typical programmer and
not a designer.
In CTJ, channels are public and the package also supports semaphores and
Hoare?s monitors but they are protected. Semaphores or monitors can be used
at special (low-level) places in software. Channels are my first choice and
fortunately I have not yet needed semaphores or monitors explicitly for
building high-quality real-time control software.

I don?t know who T_Christopher is and how important he is (he is probably a
nice guy), but I disagree with his opinion. I would like to see his fingers
each time he burns them at the multithreading stuff he likes so much.

Once Andy Bakkers wrote Daniel Berg (a well-known specialist in
multithreading and wrote the book ?Threads Primer?) and sent him an example
of mine that was made with an early version of CTJ. He replied, ?? this is
the way concurrency should be used? (this is not the exact phrase which is
on my computer at work). Andy maybe you can comment on this.

I guess T_Christopher wants to sell his book thats why he promotes
multithreading.

Concurrency should not be for specialists only. In my opinion, reading his
book would be a waste of time. Many people trust and follow books, so, maybe
we should write one for the non-specialists!

Gerald.

> -----Original Message-----
> From: Richard Beton [mailto:richard.beton@xxxxxxxxxx]
> Sent: Tuesday 23 January 2001 17:46 PM
> To: Java-Threads Mailing List
> Subject: Re: Java Live | January 9, 2001
>
>
> Re
> http://developer.java.sun.com/developer/community/chat/JavaLive/2001/jl0
> 109.html
> <http://developer.java.sun.com/developer/community/chat/JavaLive/2001/jl
> 0109.html>
> Interesting.
>
> 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/
> <http://www.sun.com/books/catalog/christopher/> ).
>
>
> Rick
>
>
>