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}).
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}.
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.
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.