RE: x2AnyChannels do not allow alting

["Gerald H. Hilderink" <g.h.hilderink@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-java-threads@xxxxxxxxx
> [mailto:owner-java-threads@xxxxxxxxx]On Behalf Of M_Boosten
> Sent: Thursday, February 17, 2000 1:33 PM
> To: java-threads@xxxxxxxxx
> Subject: x2AnyChannels do not allow alting
>
>
> Hello,
>
> While reading the JCSP API specification, I noticed the
> following in One2AnyChannel and Any2AnyChannel:
>
>   Class *2AnyChannel
>   ...
>   DESCRIPTION
>   ...
>   All reading processes and the writing process commit to the
>   channel (i.e. may not back off). This means that the reading
>   processes may not ALT on this channel.
>
> This is quite a restriction.  I can imagine that the following
> (less demanding) restriction is also sufficient:
>
>   If an ALT selects an *2AnyChannel, the process has to perform
>   an input from that channel.
>
> Is this correct?
> If my suggestion is incorrect, I would like to know why...
>
> Looking forward to an answer,
>
>   Marcel Boosten
>
> (ex CERN-employee)
>

This restriction in JCSP should prevent two or more competing ALT constructs
on a shared channel. This is because competing ALT constructs are a source
of hazardous race conditions. Therefore, in JCSP, ALT constructs only use
*2OneChannel channels to indicate that they must be the only reader on the
channel at the time. This is a way of strong-typing that enables the
compiler to check that no other channel types are connected to the ALT
constructs. In this way sources of errors 'can' be detected at compile-time,
which is a very good idea.

Unfortunately, this technique is not bullet-proof. A *2OneChannel channel
can still be used by multiple ALTs and the compiler accepts it without
complaining. The technique does not prevent one to connect multiple ALTs at
the reader side of the *2OneChannel channel. This weakness is useful for,
for example, two or more alternating ALTs (or readers) on the *2OneChannel
channel -- only one ALT (or reader) will claim the channel at the time. I
belief that the reader side of the *2OneChannel is not synchronized against
multiple readers. When one makes a programming error that causes two or more
ALTs accidentally reading the channel at the same time then a very nasty
race-hazard can occur. Tracing internal errors can be very difficult.

It's a matter of taste. CTJ is doing something similar as you suggest. The
CTJ package does not distinguish between the cardinality of multiple/single
writers and multiple/single readers. One advantage is that this reduces
restrictions and reduces the number of channel classes. All CTJ channels are
Any2AnyChannel channels. In CTJ, when a channel is accidentally being used
by competing ALTs (or readers) then a race condition is noticeable, but no
nasty internal race-hazards will occur. In that sense CTJ channels are
always thread-safe. In our documents we warn the users of the danger of
competing ALTs or competing readers.
CTJ also supports output guards, which can be very useful in some
situations, but may cause high-level race-conditions in some other
situations (e.g. a competing input guarded ALT and output guarded ALT never
commit in communication). A bold warning is written in the documents to
indicate that certain situations should be avoided. Competing ALTs,
competing readers and output guards are legal in CSP. For now, all
restrictions are written as guidelines or rules in CTJ (and in JCSP)
documents.
Maybe, in the future we may implement cardinality, but since the technique
as used in JCSP is not bullet-proof we let is rest. Instead, we prefer some
kind of preprocessor that checks the Java code for all kinds of high-level
race conditions. Design tools can check these rules as well.

Restrictions are handicaps that can be very valuable for reliable concurrent
programming.

- Gerald