org.jcsp.nxt.lang
Interface CSProcess

All Known Implementing Classes:

ActiveButtons, ActiveCopy, ActiveDisplay, ActiveLightSensor, ActiveMotor, ActiveMotor2, ActiveTouchSensor, ActiveUltrasonicSensor, BinaryFilter, IntActiveDisplay, Parallel, Skip, TernaryFilter

public interface CSProcess

This is the JCSP interface for a process - an active component that encapsulates the data structures on which it operates.

Description

A CSP process is a component that encapsulates data structures and algorithms for manipulating that data. Both its data and algorithms are private. The outside world can neither see that data nor execute those algorithms. Each process is alive, executing its own algorithms on its own data. Processes interact solely via CSP synchronising primitives, such as channels, events or other well-defined modes of access to shared passive objects.

In this JCSP binding of the CSP model into Java, a process is an instance of a class implementing this CSProcess interface. Its actions are defined by the run method.

Running processes interact solely via CSP channels, events or carefully synchronised access to shared objects -- not by calling each other's methods. These passive objects form the CSP interface to a process. They are not present in the Java interface and must be configured into each process via public constructors and/or mutators when it is not running (i.e. before and in between runs). It is safe to extract information from the process via accessor methods, but only after (or in between) runs.

For other general information, see the JCSP overview.

Process Oriented Design

A process-oriented design consists of layered networks of processes. A network is simply a parallel composition of processes connected through a set of passive synchronisation objects (wires) and is itself a process. Each process fulfills a contract with its environment that specifies not only what functions it performs, but how it is prepared to synchronise with that environment to obtain information and deliver results. Note that a process does not interact directly with other processes, only with the wires to which it is connected. This is a very familiar form of component interface -- certainly to hardware engineers -- and is one that allows considerable flexibility and reuse.

Implementation Pattern

The structure of a JCSP process should follow the outline:

 import org.jcsp.lang.*;
 ...  other imports
  
 class ProcessExample implements CSProcess {
  
   ...  private/protected shared synchronisation objects (channels etc.)
   ...  private/protected state information
  
   ...  public constructors
   ...  public configuration/inspection methods (when not running)
  
   ...  private/protected support methods (part of a run)
   ...  public run method (the process starts here)
  
 }
 

The pattern of use for these methods is simple and well-disciplined. The public constructors and configuration methods must install the shared synchronisation objects into their private/protected fields. They may also initialise other private/protected state information. The public configuration/inspection methods (simple sets and gets) may be invoked only when this process is not running and are the responsibility of a single process only -- usually the process that constructed it. That process is also responsible for invoking the public run method that kicks this one into life (usually, via a Parallel or ProcessManager intermediary). The private support methods are triggered only by the run method and express the live behaviour of this process.

A process instance may have several lives but these must, of course, be consecutive. Different instances of the same process class may, also of course, be alive concurrently. Reconfiguration of a process via its configuration/inspection methods may only take place between lives. Dynamic reconfiguration of a live process may take place -- but only with the active cooperation of the process (for example, through channel communication).

Motivation

Like any object, a process should encapsulate a coherent set of data and algorithms for managing that data. The discipline outlined in the above implementation pattern has the following broad aims:

• maintain the encapsulation of information (which is something that is easilly lost in free-wheeling OO-design as object references are passed around);
• enable a precise (CSP) specification of the way a process interacts with its environment (represented in the above pattern by the shared synchronisation objects);
• express the behaviour of the process from its own point of view (which is something not available to general OO-design whenever a method of one object is invoked from the method of another);
• eliminate the occurrence of race hazards upon the parallel composition of processes;
• enable formal certification of the absence of deadlock, livelock and process starvation in a parallel system (through design-time analysis or the checked adherence to higher-level CSP design rules for which proven safety guarantees are known).

These properties mean that processes make excellent building blocks for complex systems -- their semantics compose cleanly and predictably as they are plugged together.

This is not to say that the semantics of processes connected in parallel are simply the sum of the semantics of each individual process -- just that those semantics should contain no surprises. Value can added just through the nature of the parallel composition itself. For example, connect simple stateless processes into a channel feedback-loop, give them some external wires and we get a component that contains state.

Discussion

The public methods of an arbitrary object are at the mercy of any other object that has a reference to it. Further, invocations of those methods may be part of any thread of control. Object designers, implementors and users need to have this under well-documented control. This control is not easy to achieve without any rules.

The process design pattern defines some powerful simplifications that bring us that control. Backed up with the theory of CSP, it also addresses and offers solutions to some fundamental issues in concurrency and multi-threading.

In unconstrained OO, threads and objects are orthogonal notions -- sometimes dangerously competitive. Threads have no internal structure and can cross object boundaries in spaghetti-like trails that relate objects together in a way that has little correspondence to the original OO design. A process combines these ideas into a single concept, gives it structure and maintains strong encapsulation by guarding the distribution and use of references with some strict (and checkable) design rules. A process may be wired up in parallel with other processes to form a network -- which is itself a process. So, a process may have sub-processes that have sub-sub-processes ad infinitum. This is the way the world works ...

The simplicity of the process design pattern is that each process can be considered individually as an independant serial program, interacting with external I/O devices (the synchronisation objects -- channels etc.). At the other end of those devices may lie other processes, but that is of no concern to the consideration of this process. All our past skills and intuition about serial programming can safely be applied. The new skills needed to design and use parallel process networks sit alongside those earlier skills and no cross-interference takes place.

Author:

P.D.Austin, P.H.Welch, Alex Panayotopoulos

See Also:

, , ChannelInputInt, ChannelOutputInt,

Method Summary

void	run() This defines the actions of the process.

Method Detail

run

void run()

This defines the actions of the process.