Chapter 4 Fundamentals of occam C P H

Chapter 4 Fundamentals of occam (C) P. H. Welch 1

The Influence of Language • Language shapes our thoughts. • Traditional programming languages (FORTRAN, Pascal, C, …) are aimed at von Neuman architectures • occam is a language with parallelism at its heart (C) P. H. Welch 2

OCCAM • Simple language • Express (& reason about) sequential (MIMD) and parallel designs with equal fluency • Enforces (hardware) discipline on parallel designs: – no shared data – point-to-point communication (i. e. no contention) • Avoids many standard problems of concurrency (C) P. H. Welch 3

Simplicity of occam Parallelism • Confidence with very high levels of concurrency (say > 100, 000 parallel processes) • Fast implementations (e. g. the Transputer imposes overhead of approx. 1 sec. when switching processes) cf: Ada 100 sec (C) P. H. Welch 4

occam Communication • Synchronized • Point-to-point • Un-buffered Can construct (reusable) software components to give • • Asynchronous Broadcast (one-to-many) Multiplexed Buffered Minimal overhead – use only where necessary (C) P. H. Welch 5

Distributability of occam PAR Inter-Transputer links follow the occam primitives • Synchronized • Point-to-point • Unbuffered and they are fast… • 1. 8 Mbytes/sec (T 8/T 4/T 2) • 10 Mbytes/sec (T 9000) • Bi-directional (C) P. H. Welch 6

A System Q R S T P (C) P. H. Welch 7

System Configuration Software/Hardware configuration of parallel systems : • • 1 general-purpose processor n general-purpose processors m special-purpose processors any combination (C) P. H. Welch 8

One Processor Q R S T P (C) P. H. Welch 9

Five Processors Q R S T P (C) P. H. Welch 10

Three Processors Q R S T P (C) P. H. Welch 11

How to Balance? Ensure processors are not idle because : • Other processors are not ready to send or receive; • Traffic is being generated that is greater than the interprocessor bandwidth Otherwise, adding more processors may slow you down! We need more experience before trying to build tools to help here. (C) P. H. Welch 12

Real World Autonomous Objects • Independent behavior • Private data • Influence each other by “communication” (C) P. H. Welch 13

“Von Neumann” Machine • One object • One data space • Simulates ** many objects • sequential procedures • global state info* • scheduling code** * * implies loss of clarity ** implies inefficiency (C) P. H. Welch 14

“Parallel” Machine • Models “real world” directly • Clarity – – easier to design easier to implement easier to validate easier to maintain • Efficiency – exploit parallel hardware – design parallel hardware (C) P. H. Welch 15

A Small System Example • Two objects • The behaviour of each object is simple to describe from its own point of view (“object-oriented”) • The behaviour of the system is naturally described as the concurrent execution of each object • The behaviour of the system is hard to describe using sequential procedural ideas (C) P. H. Welch 16

B A A produces : 0, f(0), g(f(0)), f(g(f(0))), g(f(0)))), ----- where : f(n) = 1000, if n = 0 2*n, otherwise g(n) = n/3 (C) P. H. Welch 17

B A B takes data in threes. For each triple (x, y, it prints : - z), x, y, z, (x + y + z)/3 (C) P. H. Welch 18

Procedural Implementation? A calls B • B must retain its state in global data structures • Algorithm for B must be turned “inside-out” and programmed from its caller’s point-of-view (this is obscure!) (“non-object-oriented”) B calls A • A must retain its state in global data structures • Algorithm for A inverted to B’s point-of-view (again obscure) Master scheduler calls both A and B • Symmetric solution – equal misery for all! • A and B retain global state • Algorithm for both A and B inverted (C) P. H. Welch 19

Parallel Implementation Object A • State declared and retained locally (hidden from outside) • Algorithm for A direct and simple (“object-oriented”) Object B • State declared and retained locally (hidden from outside) • Algorithm for B direct and simple (“object-oriented”) System • Parallel instantiation of A and B (just as in the “real world”) (C) P. H. Welch 20

OCCAM … from the top (C) P. H. Welch 21

d c b a e P x y PROC P (CHAN OF INT a, b, CHAN OF BOOL c, CHAN OF BYTE d, e) INT x, y: . . . : Some Declarations (C) P. H. Welch 22

PROC P (CHAN OF INT a, b, CHAN OF BOOL c, CHAN OF BYTE d, e) … : PROC Q (CHAN OF INT a, b, c, CHAN OF BOOL d) … : PROC R (CHAN OF BYTE a, b) … : (C) P. H. Welch d c b e P a a Q b a d c R b 23

a PROC S (CHAN OF INT a, b, CHAN OF BOOL c, CHAN OF INT d) … : b c S d a PROC T (CHAN OF BYTE a, CHAN OF BOOL b, CHAN OF BYTE c) … : b T c (C) P. H. Welch 24

b f c h e a g i d j CHAN OF INT a, b, c, d: CHAN OF BYTE f, h, I, j: CHAN OF BOOL e, g: (C) P. H. Welch 25

R Q CHAN OF PAR P (a, Q (a, R (f, R (j, S (b, T (h, INT a, b, c, d: BYTE f, h, i, j: BOOL e, g: d, b, h) i) c, g, e, f, j) c, e) d, g) i) b f c h e S a T g i d R P Spot the Mistake (C) P. H. Welch j 26

Rendezvous c P 0 P 1 CHAN OF INT c: PAR P 0(c) P 1(c) (C) P. H. Welch 27

PROC P 0 (CHAN OF INT out). . . out ! value. . . PROC P 1 (CHAN OF INT in). . . in ? x. . . (C) P. H. Welch P 0 in out P 0 28

Synchronized Unbuffered Communication out ! value • Output value down the channel out • This operation does not complete until the process at the other end of the channel inputs the information • Until that happens, the outputting process sleeps (possibly forever!) (C) P. H. Welch 29

Synchronized Unbuffered Communication in ? x • Input the next piece of information from channel in into the variable x • This operation does not complete until the process at the other end of the channel outputs the information • Until that happens, the inputting process sleeps (possibly forever!) • The inputting process can set “timeouts” on these inputs or choose between alternative inputs. [We will do this later] (C) P. H. Welch 30

“Rendezvous” Concept • Unified concept of synchronisation + unbuffered communication. • Asynchronous and buffered communication easy to construct. • Incoming rendezvous selectable • Hardware model: it is fast to implement • Hardware model: our intuition enables us to reason about it (C) P. H. Welch 31

OCCAM . . . from the bottom (C) P. H. Welch 32

Types INT, BYTE, BOOL INT 16, INT 32, INT 64 REAL 32, REAL 64 Primitive [100]INT [32][8] BYTE []REAL 64 Arrays Constant Abbreviations VAL INT max IS 50: VAL INT double. max is 2*max: VAL BYTE letter IS 'A': VAL []BYTE string IS "Hello*c*n": VAL [8]INT masks is [#01, #02, #04, #08, #10, #20, #40, #80] (C) P. H. Welch 33

Operators +, -, *, /, PLUS, MINUS, TIMES +, -, *, / <, <=, > =, <> INT, INT REAL, REAL INT, INT BOOL BYTE, BYTE BOOL REAL, REAL BOOL *. * BOOL STRONG TYPING (C) P. H. Welch 34

Operators AND, OR NOT /, /, >< ~ BOOL, BOOL INT, INT <<, >> INT, INT AFTER INT, INT BOOL STRONG TYPING (C) P. H. Welch 35

Variable Declarations INT a, b: [max]INT c: [double. max]BYTE d: Timer Declarations TIMER tim: Channel Declarations CHAN OF BYTE p: [max<<2]CHAN OF INT q: (C) P. H. Welch 36

Process Abstractions PROC fred (VAL []BYTE s, VAL BOOL mode, INT result, CHAN OF INT in, out, CHAN OF BYTE pause). . . : VAL <type> <id> in fred (s, mode, result) pause out “value” parameters – local constants within the PROC body “reference” parameters (C) P. H. Welch 37

An occam Process (Optional) Sequence of Declarations (Single) Executable Process (C) P. H. Welch 38

Primitive Processes Assignment a : = c[2] + b Input (Synchronising) in ? a STRONG TYPING Output (Synchronising) out ! a + (2*b) (C) P. H. Welch 39

Primitive Processes TIMER (read) tim ? t Timeout (wait until specified time) TIMER tim: INT t: tim ? AFTER t PLUS 3000 Null SKIP Suspend (non-recoverable) STOP (C) P. H. Welch 40

Structured Processes SEQ Do these 4 processes in the sequence written SEQ in ? sum in ? x sum : = sum + x out ! sum (C) P. H. Welch 41

in in. 0 in. 1 x sum x. 0 x. 1 a out b out c (C) P. H. Welch 42

Structured Processes PAR Do these 4 processes in parallel PAR in. 0 ? x. 0 in. 1 ? x. 1 out ! a + b c : = a + (2*b) Assign/input to same var Write to same chan Read from same chan (C) P. H. Welch 43

Structured Processes IF <boolean> Tests evaluated in sequence; process of the first one TRUE is executed. IF x > 0 screen ! 'p' x < 0 screen ! 'n' TRUE screen ! 'z' If all the boolean tests are FALSE, a run-time error is raised. (C) P. H. Welch 44

Structured Processes WHILE <boolean> Conventional “while-loop” in double out PROC double (CHAN OF INT in, out) WHILE TRUE INT x: SEQ in ? x out ! 2*x : (C) P. H. Welch 45