This provides classes and interfaces corresponding to the fundamental
primitives of CSP.
Processes, Networks and Synchronisation
In JCSP, a process is an instance of a class implementing the
{@link org.jcsp.lang.CSProcess} interface - its behaviour being determined
by the implementation of its run() method. Processes may be composed
in {@link org.jcsp.lang.Sequence} or {@link org.jcsp.lang.Parallel} (or {@link org.jcsp.lang.PriParallel}),
the result of this composition being another process. Processes may also be spawned
to run concurrently with the spawning process - see {@link org.jcsp.lang.ProcessManager}.
A collection of parallel processes is called a network.
Processes encapsulate both data and algorithms. Parallel processes interact
either by synchronised communication along {@link org.jcsp.lang.Channel}s
(the cleanest and simplest way) or by synchronised access to shared
objects. The latter synchronisation may be achieved through channel signals
or by a range of other JCSP primitives (such as {@link org.jcsp.lang.Barrier},
{@link org.jcsp.lang.AltingBarrier},
{@link org.jcsp.lang.Bucket} or {@link org.jcsp.lang.Crew}).
Channels
Channels come in two varieties: those that carry Object references and
those that carry ints. For completeness, JCSP should provide channels
specific to all the Java primitive types. These could trivially be added but,
so far, do not seem to be needed in practice.
Specialised channels, using Java generics, are easy to add and will be done
soon – please mail us if you have urgent need.
Channels (from the Point of View of a Process)
Processes should drive their channels through channel ends:
{@link org.jcsp.lang.ChannelInput} / {@link org.jcsp.lang.ChannelOutput} (for Object channels)
and {@link org.jcsp.lang.ChannelInputInt} / {@link org.jcsp.lang.ChannelOutputInt} (for int channels).
To allow choice of receiving input (see next paragraph), processes must drive
their channels through {@link org.jcsp.lang.AltingChannelInput} / {@link org.jcsp.lang.AltingChannelInputInt}
(rather than {@link org.jcsp.lang.ChannelInput} / {@link org.jcsp.lang.ChannelInputInt}).
Processes may passively wait for a number of events using {@link org.jcsp.lang.Alternative}.
These events include channel inputs
({@link org.jcsp.lang.AltingChannelInput} / {@link org.jcsp.lang.AltingChannelInputInt}),
channel accepts
({@link org.jcsp.lang.AltingChannelAccept}),
alting barriers ({@link org.jcsp.lang.AltingBarrier}),
timeouts ({@link org.jcsp.lang.CSTimer}) and skips ({@link org.jcsp.lang.Skip}).
If more than one event is ready, an {@link org.jcsp.lang.Alternative#select() arbitrary},
{@link org.jcsp.lang.Alternative#priSelect() prioritised}
or {@link org.jcsp.lang.Alternative#select() fair} choice can be made between them.
The super-interface for all these ALTable events is {@link org.jcsp.lang.Guard}.
Channels (from the Point of View of a Network)
Actual channels must be constructed by the {@link org.jcsp.lang.Parallel} network builder
with appropriate channel ends passed to the processes needing them (usually via their constructors).
Four varieties are available for Object channels:
{@link org.jcsp.lang.One2OneChannel}, {@link org.jcsp.lang.Any2OneChannel},
{@link org.jcsp.lang.One2AnyChannel} and {@link org.jcsp.lang.Any2AnyChannel}.
Similarly, four varieties are available for int channels:
{@link org.jcsp.lang.One2OneChannelInt}, {@link org.jcsp.lang.Any2OneChannelInt},
{@link org.jcsp.lang.One2AnyChannelInt} and {@link org.jcsp.lang.Any2AnyChannelInt}.
Please note that the last two in each set are not broadcasting channels
- broadcasting has to be achieved by active processes (e.g. {@link org.jcsp.plugNplay.Delta}).
Channels are constructed by the static manufacturing methods of
the {@link org.jcsp.lang.Channel} class.
Input and output channel ends are obtained from channels by their in() and out
methods, respectively.
Note that the default semantics for all the above channels are zero-buffering and full
synchronisation. This means that a writer to a channel will wait for a matching reader
and vice-versa - whoever gets to the channel first will wait
for its partner. Various forms of buffering can be introduced by splicing active
buffer processes into these channels. However, because this is a common need,
JCSP provides a range of plug-ins that can be used to create channels
with the common varieties of buffering:
{@link org.jcsp.util.Buffer blocking FIFO
},
{@link org.jcsp.util.OverWriteOldestBuffer overwriting (oldest) FIFO
},
{@link org.jcsp.util.OverWritingBuffer overwriting (latest) FIFO
} and
{@link org.jcsp.util.InfiniteBuffer infinite FIFO
}.
That set of plug-ins is for Object channels and comes from
the {@link org.jcsp.util} package.
A similar set for int channels is provided in {@link org.jcsp.util.ints}.
It is the network builder's responsibility to decide whether to use 1-1,
any-1, 1-any or any-any channels and whether to incorporate
buffers in them.
The process designer is not concerned with these decisions - only with whether
the channel is for input or output and what type of information it carries.
Call Channels
Call Channels provide a method interface for client-server communication between active
processes, yet their semantics remain those of a synchronising zero-buffered channel.
Without them, we would normally have to set up a pair of channels (giving bi-directional
communication) and use a sequence of channel write(s) and read (at the client end)
matched by a sequence of channel read(s) and write (at the server end).
The client process sees a server-specific method interface and invokes it in the normal
way - however, the invocation will block until the server chooses to accept the call.
The server sees the {@link org.jcsp.lang.ChannelAccept} interface - invoking
an {@link org.jcsp.lang.ChannelAccept#accept accept} will block until the client
makes a call.
The network builder constructs a server-specific actual call channel by sub-classing
from one of
{@link org.jcsp.lang.One2OneCallChannel}, {@link org.jcsp.lang.Any2OneCallChannel},
{@link org.jcsp.lang.One2AnyCallChannel} and {@link org.jcsp.lang.Any2AnyCallChannel}.
Precise rules for making this extension are given in their documentation.
Symmetric Channels
Thanks to alting barriers ({@link org.jcsp.lang.AltingBarrier}),
symmetric channels are now available:
{@link org.jcsp.lang.One2OneChannelSymmetric} and {@link org.jcsp.lang.One2OneChannelSymmetricInt}.
These work the same as ordinary channels but, in addition, their output ends
can be used as guards in a choice ({@link org.jcsp.lang.Alternative}).
It is quite safe for both the sending and receiving process to be alting
on these symmetric channels.