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

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

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

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

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

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

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

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 :-

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

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

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

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.

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

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

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

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

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

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

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 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

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”)

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

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

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) … :

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) … :

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

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

27. (C) P. H. Welch27 Rendezvous P0P1 c CHAN OF INT c: PAR P0(c) P1(c)

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.

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

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

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

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

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

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

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

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<<2]CHAN OF INT q:

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

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

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

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

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

42. (C) P. H. Welch42 in out xsum out in.1 in.0 cx.1 bax.0

43. (C) P. H. Welch43 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

44. (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.

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