RE: x2AnyChannels do not allow alting

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

Peter,

(snip)
>
> But in JCSP, I prefered to offer the user a variety of 1-*, *-1 and *-*
> channels.  This lets the designer document how he/she intends to use the
> channel (and a tool - but not the compiler - could verify this).  Another
> benefit is that the application suffers only the synchronisation overheads
> it needs.  Another *benefit* (and this gets back to Marcel's question) is
> that once you have declared a 1-* or *-* channel, the compiler will not
> allow a reader to ALT on it.  As Gerald notes:
>
> > 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.
>
> So, in JCSP, you expose yourself to a channel race hazard if and
> only if you deliberately set more than one process to work at the end of a
> channel that has been declared for use by only one.
>

These are benefits that I really like about this approach.

A long time ago I have also thought of classifying 1-*, *-1 and *-*
channels, but I was afraid that the number of different classes would
mess-up the code. Another reason I did not implement this is that it could
be too restrictive for creating dynamic networks of processes. CTJ is
focused on other important issues and cardinality could cause some
undesirable restrictions on this research. So cardinality became a low
priority (but important) subject.

Another important issue why CTJ is a bit different from JCSP is to encourage
a healthy competition between JCSP and CTJ :-) :-)
To many problems there may exist more than one good solution.

Currently, CTJ is focused on subjects, such as:
- real-time performance and embedded features (i.e. in native code);
  includes a special kernel supporting preemptive and non-preemptive
scheduling,
  fast context switching, composing priorities, and the support of a hard
real-time clock
  for timing and timeout events.
- external channel communication based on link drivers;
  interrupt handling is seen as part of communication and not as a higher
level process.
  Link drivers provide communication by devices, communication with
AWT/Swing threads,
  communication with other processors and more?
- notion of priority; CTJ supports a real PRIPAR, a real ALT and a real
PRIALT, which
  priorities can be influenced by the PRIPAR for better real-time
performance
  (ideas from Burns and Wellings). Interesting stuff for Occam4.
- The previous subjects have been implemented in native C and C++ code as
copies of CTJ and
  the results are very nice.

> The *2Any channel does this for readers.  In effect, the channel is ALTing
> over attempted outputs to each of those readers - i.e. there are output
> guards.  It follows, therefore, that allowing any of those readers also
> to ALT over a channel input is *either* going to be unsafe (there will
> be a race hazard disaster sometime) *or* there needs to be a complex and
> time-consuming policing action to sort things out.  That's why output
> guards are not allowed in occam (nor in JCSP).

The performance penalty or complexity of having output guards was a problem
for the transputer implementation approach. In CTJ, the performance penalty
or complexity of the implementation of output guards is very low. In cases
where output guards are useful, output guarded ALTS are much faster than
using input guarded ALTs with request and reply channels.

The CTJ ALTs can throw an exception when two or more (input/output guarded)
ALTS are competing at the same time at run-time. This has not been
implemented, because the cost of these checks are a bit high and I prefer
compile-time checking over run-time checking.

Gerald.