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.