Slide 1

(C) P. H. Welch1 Chapter 4 Fundamentals of occam Slide 2 (C) P. H. Welch2 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 Slide 3 (C) P. H. Welch3 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 Slide 4 (C) P. H. Welch4 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 Slide 5 (C) P. H. Welch5 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 Slide 6 (C) P. H. Welch6 Distributability of occam PAR Synchronized Point-to-point Unbuffered Inter-Transputer links follow the occam primitives and they are fast 1.8 Mbytes/sec (T8/T4/T2) 10 Mbytes/sec (T9000) Bi-directional Slide 7 (C) P. H. Welch7 A System Q R S P T Slide 8 (C) P. H. Welch8 System Configuration 1 general-purpose processor n general-purpose processors m special-purpose processors any combination Software/Hardware configuration of parallel systems :- Slide 9 (C) P. H. Welch9 One Processor Q R S P T Slide 10 (C) P. H. Welch10 Five Processors Q R S P T Slide 11 (C) P. H. Welch11 Three Processors Q R S P T Slide 12 (C) P. H. Welch12 How to Balance? Other processors are not ready to send or receive; Traffic is being generated that is greater than the interprocessor bandwidth Ensure processors are not idle because :- Otherwise, adding more processors may slow you down! We need more experience before trying to build tools to help here. Slide 13 (C) P. H. Welch13 Real World Autonomous Objects Independent behavior Private data Influence each other by communication Slide 14 (C) P. H. Welch14 Von Neumann Machine One object One data space Simulates ** many objects sequential procedures global state info* scheduling code** * * implies loss of clarity ** implies inefficiency Slide 15 (C) P. H. Welch15 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 Slide 16 (C) P. H. Welch16 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 Slide 17 (C) P. H. Welch17 A B A produces :- 0, f(0), g(f(0)), f(g(f(0))), g(f(g(f(0)))), ----- where :- f(n) = 1000, if n = 0 2*n,otherwise g(n) = n/3 Slide 18 (C) P. H. Welch18 A B B takes data in threes. For each triple (x, y, z), it prints :- x, y, z, (x + y + z)/3 Slide 19 (C) P. H. Welch19 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 callers 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 Bs 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 Slide 20 (C) P. H. Welch20 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) Slide 21 (C) P. H. Welch21 OCCAM from the top Slide 22 (C) P. H. Welch22 P c d b a e x y PROC P (CHAN OF INT a, b, CHAN OF BOOL c, CHAN OF BYTE d, e) INT x, y:. : Some Declarations Slide 23 (C) P. H. Welch23 PROC P (CHAN OF INT a, b, CHAN OF BOOL c, CHAN OF BYTE d, e) : P c d b a e PROC Q (CHAN OF INT a, b, c, CHAN OF BOOL d) : Q c d b a R b a PROC R (CHAN OF BYTE a, b) : Slide 24 (C) P. H. Welch24 PROC S (CHAN OF INT a, b, CHAN OF BOOL c, CHAN OF INT d) : S b a c d T b a c PROC T (CHAN OF BYTE a, CHAN OF BOOL b, CHAN OF BYTE c) : Slide 25 (C) P. H. Welch25 CHAN OF INT a, b, c, d: CHAN OF BYTE f, h, I, j: CHAN OF BOOL e,g: a b c e f d g j i h Slide 26 (C) P. H. Welch26 a b c e f d g j Q R S P T R i h CHAN OF INT a, b, c, d: CHAN OF BYTE f, h, i, j: CHAN OF BOOL e,g: PAR P (a, d, e, f, j) Q (a, b, c, e) R (f, h) R (j, i) S (b, c, d, g) T (h, g, i) Spot the Mistake Slide 27 (C) P. H. Welch27 Rendezvous P0P1 c CHAN OF INT c: PAR P0(c) P1(c) Slide 28 (C) P. H. Welch28 PROC P0 (CHAN OF INT out). out ! value. P0 out P0 in PROC P1 (CHAN OF INT in). in ? x. Slide 29 (C) P. H. Welch29 Synchronized Unbuffered Communication 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!) out ! value Slide 30 (C) P. H. Welch30 Synchronized Unbuffered Communication 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] in ? x Slide 31 (C) P. H. Welch31 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 Slide 32 (C) P. H. Welch32 OCCAM... from the bottom Slide 33 (C) P. H. Welch33 INT, BYTE, BOOL INT16, INT32, INT64 REAL32, REAL64 Primitive 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] TypesTypes Constant Abbreviations [100]INT [32][32][8] BYTE []REAL64 Arrays Slide 34 (C) P. H. Welch34 +, -, *, /, \ PLUS, MINUS, TIMES INT, INT INT +, -, *, / REAL, REAL REAL =, > INT, INT BOOL BYTE, BYTE BOOL REAL, REAL BOOL =,*.* BOOL STRONG TYPING OperatorsOperators Slide 35 (C) P. H. Welch35 BOOL, BOOL BOOL INT, INT INT STRONG TYPING AND, OR NOT BOOL BOOL /\, \/, >< ~ INT INT > INT, INT INT AFTER INT, INT BOOL OperatorsOperators Slide 36 (C) P. H. Welch36 Variable Declarations INT a, b: [max]INT c: [double.max]BYTE d: Timer Declarations TIMER tim: Channel Declarations CHAN OF BYTE p: [max (C) P. H. Welch44 Structured Processes IF 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. Slide 45 (C) P. H. Welch45 Structured Processes WHILE Conventional while-loop PROC double (CHAN OF INT in, out) WHILE TRUE INT x: SEQ in ? x out ! 2*x : in out double