Re: Channels versus Methods

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Thomas,

Rick Beton wrote:

> Thomas Umland wrote:
> 
> >   public synchronized Object read (CallChannelFunctionInterface
> >                                    function) {
> >     if (data.getState () == ChannelDataStore.EMPTY) {
> 
> Is this the pathological wait/notify Pooh-trap? I think you might need
>     while (data.getState () == ChannelDataStore.EMPTY) {
> 
> instead. (Someone will correct me if I'm wrong, no doubt)
> 
> Rick

and you replied:

> to make things easier for me I just copied the original JCSP code ;-)

The JCSP code is correct.  There is no need for a while-loop.  Things
are arranged so that there can only be *one* reader executing this method
(whether for a One2OneChannel or ...2ManyChannel).  So that one reader is
the only Java thread that will receive the notify from a writer - i.e.
noone else can sneak in and make the ChannelDataStore.EMPTY again.

> I would prefer not catching the exception at all and instead make the
> whole read statement fail:

This is another matter.  CJT does this and so did JCSP in its early versions.
The trouble is that exporting this exception back like this forces really
horrible try-catch blocks around any code that includes channel communications.
Real ugly and distracting!

If you really want to throw an exception (rather than just ignoring it),
keep the try-catch clause in the read/write methods and convert the
InterruptedException (in the catch clause) into a RuntimeException and
declare that as (maybe) being thrown in the method header.  Then, user
code is not obliged to put in the try-catch clauses around comms code.

But the whole InterruptedException thing is irrelevant if you are following
the CSP design pattern - it never happens.  I'm not sure, but I suspect that
that whole mechanism is something to do with some funny termination or
deadlock-recovery scheme.  But it's mysterious, not explained and best
suppressed!  ;-)

Peter.