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 jcsp.lang.CSProcess} interface - its behaviour being determined by the implementation of its run() method. Processes may be composed in {@link jcsp.lang.Sequence} or {@link jcsp.lang.Parallel} (or {@link 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 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 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 jcsp.lang.Barrier}, {@link jcsp.lang.AltingBarrier}, {@link jcsp.lang.Bucket} or {@link 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.

Channels (from the Point of View of a Process)

Processes should drive their channels through channel interfaces: {@link jcsp.lang.ChannelInput} / {@link jcsp.lang.ChannelOutput} (for Object channels) and {@link jcsp.lang.ChannelInputInt} / {@link jcsp.lang.ChannelOutputInt} (for int channels).

Processes may passively wait for a number of events using {@link jcsp.lang.Alternative}. These events include channel inputs ({@link jcsp.lang.AltingChannelInput} / {@link jcsp.lang.AltingChannelInputInt}), channel accepts ({@link jcsp.lang.AltingChannelAccept}), alting barriers ({@link jcsp.lang.AltingBarrier}), timeouts ({@link jcsp.lang.CSTimer}) and skips ({@link jcsp.lang.Skip}). If more than one event is ready, an {@link jcsp.lang.Alternative#select() arbitrary}, {@link jcsp.lang.Alternative#priSelect() prioritised} or {@link jcsp.lang.Alternative#select() fair} choice can be made between them. The super-interface for all these ALTable events is {@link jcsp.lang.Guard}.

Channels (from the Point of View of a Network)

Actual channels must be constructed by the {@link jcsp.lang.Parallel} network builder and passed to the processes needing them (usually via their constructors). Four varieties are available for Object channels: {@link jcsp.lang.One2OneChannel}, {@link jcsp.lang.Any2OneChannel}, {@link jcsp.lang.One2AnyChannel} and {@link jcsp.lang.Any2AnyChannel}. Similarly, four varieties are available for int channels: {@link jcsp.lang.One2OneChannelInt}, {@link jcsp.lang.Any2OneChannelInt}, {@link jcsp.lang.One2AnyChannelInt} and {@link 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 jcsp.plugNplay.Delta}).

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 jcsp.util.Buffer blocking FIFO}, {@link jcsp.util.OverWriteOldestBuffer overwriting (oldest) FIFO}, {@link jcsp.util.OverWritingBuffer overwriting (latest) FIFO} and {@link jcsp.util.InfiniteBuffer infinite FIFO}. That set of plug-ins is for Object channels and comes from the {@link jcsp.util} package. A similar set for int channels is provided in {@link 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 jcsp.lang.ChannelAccept} interface - invoking an {@link 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 jcsp.lang.One2OneCallChannel}, {@link jcsp.lang.Any2OneCallChannel}, {@link jcsp.lang.One2AnyCallChannel} and {@link jcsp.lang.Any2AnyCallChannel}. Precise rules for making this extension are given in their documentation.