Process-Based Concurrent ProgrammingThe Transputer as a Hardware Platform
Inmos Limited developed the transputer product starting in the early 1980s. The name 'transputer' generally refers to their family of processors, which were available in a wide range of hardware configurations. The earliest transputer, the T212, used a 16-bit memory bus width and contained 2K of on-chip RAM. Later transputers, such as the T414 and T800, were 32-bit machines with up to 4K of on-chip RAM and linear address spaces encompassing up to 4GB (Brookes, 1989).
Inmos developed the programming language occam simultaneously with their work on the transputer. The primary design goal of occam was to provide a simple yet robust language effectively expressing the process concurrency and parallelism directly available with the transputer hardware. While the transputer actually executed a lower-level assembly language, and compilers were available for C, Pascal, and FORTRAN, only occam supported the full feature set exploiting the transputer's parallelism.
Concurrent and Parallel Software
The concepts of concurrent and parallel processes are extremely similar yet distinct. Concurrent processes are processes which may be executed in parallel. In general, concurrent processes must obey a particular set of restrictions, avoiding nasty surprises such as deadlock, livelock, and output hazards through a data dependency analysis. If only one processor is available, then concurrent software is executed sequentially as usual. When more processors are available, the execution becomes parallel when several concurrent processes are executed at the same time.
Occam's greatest strength is its flexible support of concurrency, and the transputer's greatest feature is its implementation of parallelism. Occam treats everything as a process: single statements, groups of statements, procedures, functions, and even programs are considered processes that may be concurrent. In a system of one transputer, multiple processes are forced to execute on that single transputer (see Figure 1). But if multiple transputers are available, specific processes may be mapped to different transputers, executing the concurrent processes in parallel (see Figure 2).
|Figure 1: Three communicating processes on one transputer||Figure 2: Three communicating processes on two transputers|
The transputer is not just a standard microcontroller! Its process-based execution model requires it to contain a small hardware-based operating system to perform context switching for processes. In addition to managing processes local to a transputer, the system must be aware its processes executing on remote transputers as well. The distribution of processes to transputers remains in the purview of the occam programmer, who may connect transputers in a variety of networks to directly support a particular concurrent algorithm with a specific parallel processing network.
Next: Transputer Networks
Return to Index