1. © P. H. Welch1 Applying... Chapter 6

2. © P. H. Welch2 Integrator Component with Reset Line int.2 in out reset PROC int.2 (CHAN OF REAL64 in, reset, out) -- WARNING: reset before use!!! -- WARNING: reset before use!!! REAL64 total: REAL64 total: WHILE TRUE WHILE TRUE PRI ALT PRI ALT reset ? total reset ? total SKIP SKIP REAL64 x: REAL64 x: in ? x in ? x SEQ SEQ total := total + x total := total + x out ! total out ! total:

3. © P. H. Welch3 Inertial Navigation Component in pos vel acc p.resetv.reset PROC nav.comp (CHAN OF REAL64 in, v.reset, p.reset, acc, vel, pos) acc, vel, pos) :

4. © P. H. Welch4 Inertial Navigation Component PROC nav.comp (CHAN OF REAL64 in, v.reset, p.reset, acc, vel, pos) acc, vel, pos) CHAN OF REAL64 a, b, c: CHAN OF REAL64 a, b, c: PAR PAR delta (in, acc, a) delta (in, acc, a) delta (b, vel, c) delta (b, vel, c) int2 (a, v.reset, b) int2 (a, v.reset, b) int.2 (c, p.reset, pos) int.2 (c, p.reset, pos): in pos vel acc p.resetv.reset a b c int.2

5. © P. H. Welch5 Memory Cell write read read.req PROC mem.cell (CHAN OF INT write, CHAN OF BOOL read.req, CHAN OF BOOL read.req, CHAN OF INT read) CHAN OF INT read) -- WARNING: write before reading! -- WARNING: write before reading! INT x: INT x: WHILE TRUE WHILE TRUE ALT ALT write ? x write ? x SKIP SKIP BOOL any: BOOL any: read.req ? any read.req ? any read ! x read ! x:

6. © P. H. Welch6 Asynchronous Communication A sends information to B A can send at any time (it will never be blocked by B not being ready to receive) B can receive data at any time but, first, it has to “request” some (it will never be blocked by A not being able to send) The memory cell acts as a common “pool” of information A B

7. © P. H. Welch7 req in out prompt PROC prompt (CHAN OF INT in, CHAN OF BOOL req, CHAN OF BOOL req, CHAN OF INT out) CHAN OF INT out) WHILE TRUE WHILE TRUE INT x: INT x: SEQ SEQ req ! TRUE req ! TRUE in ? x in ? x out ! x out ! x: PROC async (CHAN OF INT in, out) CHAN OF INT b: CHAN OF INT b: CHAN OF BOOL a: CHAN OF BOOL a: PAR PAR mem.cell (in, a, b) mem.cell (in, a, b) prompt (b, a, out) prompt (b, a, out): in b a prompt out async

8. © P. H. Welch8 A sends information to B asynchronously B does not now have to be adapted to request data Aasync B These issues will be crucial for the proper management of a real-time environment WARNING: async buffers two items of data. One of these (that held inside the prompt) may get rather stale! WARNING: async buffers two items of data. One of these (that held inside the prompt) may get rather stale!

9. © P. H. Welch9 Regular Events clock (cycle) tick PROC clock (VAL INT cycle, CHAN OF BOOL tick) TIMER tim: TIMER tim: INT t: INT t: SEQ SEQ tim ? t tim ? t WHILE TRUE WHILE TRUE SEQ SEQ t := t PLUS cycle t := t PLUS cycle tim ? AFTER t tim ? AFTER t tick ! TRUE tick ! TRUE: Run this at high priority!!

10. © P. H. Welch10 clock (cycle) regular data flow irregular Run all these at high priority

11. © P. H. Welch11 Traditional “Ring” Buffer buffer has a capacity of max (say). A process may send its data into the buffer until it is full. If it then tries to send more, the source process will get blocked until the buffer gets emptier. A process may extract data (by first making a request) until the buffer is empty. If it then request more, the sink gets blocked until the buffer gets some data. req in out buffer

12. © P. H. Welch12 Within the buffer are declared:- 0 1 2 3 4 5 6 7 8 9 10 11 max-1 buff size 5 lo 5 hi 10

13. © P. H. Welch13 req in out buffer PROC buffer (CHAN OF INT in, CHAN OF BOOL req, CHAN OF BOOL req, CHAN OF INT out) CHAN OF INT out) [max]INT buff: [max]INT buff: INT lo, hi, size : -- size = hi – lo INT lo, hi, size : -- size = hi – lo SEQ SEQ lo, hi, size := 0, 0, 0 lo, hi, size := 0, 0, 0 WHILE TRUE WHILE TRUE ALT ALT (size < max) & in ? buff[hi] (size < max) & in ? buff[hi] SEQ SEQ hi := (hi + 1)\max hi := (hi + 1)\max size := size + 1 size := size + 1 BOOL any: BOOL any: (size > 0) & req ? any (size > 0) & req ? any SEQ SEQ out ! buff[lo] out ! buff[lo] lo := (lo + 1)\max lo := (lo + 1)\max size := size – 1 size := size – 1:

14. © P. H. Welch14 Note: We have to give the reading process the responsibility for making a request to the buffer for output. Output guards are not allowed (for implementation reasons), despite their semantic power – e.g...... WHILE TRUE ALT ALT (size < max) & in ? buff[hi] (size < max) & in ? buff[hi] SEQ SEQ hi := (hi + 1)\max hi := (hi + 1)\max size := size + 1 size := size + 1 (size > 0) & out ! buff[lo] -- not allowed  (size > 0) & out ! buff[lo] -- not allowed  SEQ SEQ lo := (lo + 1)\max lo := (lo + 1)\max size := size – 1 size := size – 1...

15. © P. H. Welch15 Output guards impose an excessive overhead on the run-time system in order to manage secure synchronization:- a b ALT a ? x a ? x b ! n b ! n ALT a ! m a ! m b ? y b ? y How do we arrange for both processes to agree which communication to perform? It can be carried out, but it’s expensive in execution time. Ada has (the equivalent to) output guards!

16. © P. H. Welch16 NOTE: The capacity of new.buffer is (max + 1) We can always provide a small process to relieve the actual reading process from having to request output: a in b buffer prompt out new.buffer PROC new.buffer (CHAN OF INT in, out) CHAN OF BOOL a: CHAN OF BOOL a: CHAN OF INT b: CHAN OF INT b: PAR PAR buffer (in, a, b) buffer (in, a, b) prompt(b, a, out) prompt(b, a, out):

17. © P. H. Welch17 NOTE: a parallel implementation is symmetric and much simpler: id new.buffer in out (max + 1) PROC new.buffer (CHAN OF INT in, out) [max]CHAN OF INT c: [max]CHAN OF INT c: PAR PAR id (in, c[0]) id (in, c[0]) id (c[max – 1], out) id (c[max – 1], out) PAR i = 0 FOR max – 1 PAR i = 0 FOR max – 1 id(c[i], c[i+1]) id(c[i], c[i+1]): c[0] c[1]

18. © P. H. Welch18 Exercise: req in out overflow.buffer error This is the same as buffer, except that it does not block the source when it is full. Instead, it outputs a signal on the ( BOOL ) error line and discards the incoming datum. (This type of buffer is of use in a real-time system where it is important not to delay the source process if the sink is slow and it is not crucial if we miss some items, so long as we know about it!)

19. © P. H. Welch19 Exercise (cont.): Demonstrate by using it as a “type ahead” buffer: plex overflow.buffer slow.process slow.process translates lower to upper case (and leaves others unchanged). slow.process waits at least one second after inputting a character before outputting. plex rings a bell if it is signalled by overflow.buffer.

20. © P. H. Welch20 req in out overwriting.buffer Exercise: This is also similar to buffer – but it also does not block the source when it is full. It differs from the overflow.buffer in that new incoming data will overwrite the oldest data that has not been output. (This type of buffer is of use in a real-time system where it is important not to delay the source process if the sink is slow and it is not crucial if we miss some items, so long as we know the latest value.)

21. © P. H. Welch21 More Parallel Design Down to “Stateless” Components int.2mem.cellEarlier implementations of int.2 and mem.cell retained state information with conventional sequential techniques (i.e. state variables) The following implementations retain state information just by the topology (feedback loops) of the connections. The internal components do not themselves retain state. They give a design for hardware implementation.

22. © P. H. Welch22 in c b out a d + any reset int.2 PROC int.2 (CHAN OF REAL64 in, reset, out) -- WARNING: reset before use!!! -- WARNING: reset before use!!! CHAN OF REAL64 a, b, c, d: CHAN OF REAL64 a, b, c, d: PAR PAR plus(in, d, a) plus(in, d, a) delta (a, out, b) delta (a, out, b) replace (b, reset, c) replace (b, reset, c) REAL64 any: REAL64 any: prefix (any, c, d) prefix (any, c, d): scope of any

23. © P. H. Welch23 in reset out PROC replace (CHAN OF REAL64 in, reset, out) WHILE TRUE WHILE TRUE PRI ALT PRI ALT REAL64 x, any: REAL64 x, any: reset ? x -- replace the reset ? x -- replace the PAR -- next ‘in’ PAR -- next ‘in’ in ? any -- with the in ? any -- with the out ! x -- ‘reset’ value out ! x -- ‘reset’ value REAL64 x: REAL64 x: in ? x -- normally in ? x -- normally out ! x -- just copy through out ! x -- just copy through

24. © P. H. Welch24 PROC mem.cell (CHAN OF INT write, CHAN OF BOOL read.req, CHAN OF INT read) CHAN OF INT read) -- WARNING: write before reading!!! -- WARNING: write before reading!!! CHAN OF INT a, b, c: CHAN OF INT a, b, c: PAR PAR replace (c, write, a) replace (c, write, a) sample (a, b, read.req, read) sample (a, b, read.req, read) INT any: INT any: prefix (any, b, c) prefix (any, b, c): any c b a read read.req write scope of any

25. © P. H. Welch25 ans req out in PROC sample (CHAN OF INT in, out, CHAN OF BOOL req, CHAN OF INT ans) CHAN OF INT ans) WHILE TRUE WHILE TRUE PRI ALT PRI ALT BOOL any: BOOL any: req ? any req ? any INT x: INT x: SEQ SEQ in ? x in ? x PAR PAR ans ! x -- duplicate ans ! x -- duplicate out ! x -- output out ! x -- output INT x: INT x: in ? x -- normal in ? x -- normal out ! x -- copy out ! x -- copy:

26. © P. H. Welch26 any d c a read read.req write b video.out PROC video.ram.cell (CHAN OF INT write, video.out, CHAN OF BOOL read.req, CHAN OF BOOL read.req, CHAN OF INT read) CHAN OF INT read) -- WARNING: write before viewing!!! -- WARNING: write before viewing!!! CHAN OF INT a, b, c, d: CHAN OF INT a, b, c, d: PAR PAR replace (d, write, a) replace (d, write, a) delta (a, video.out, b) delta (a, video.out, b) sample (b, c, read.req, read) sample (b, c, read.req, read) INT any: INT any: prefix (any, c, d) prefix (any, c, d):

27. © P. H. Welch27 Some More Examples… Compiler Programming support environment Real-time inference engines Fast fourier transform Shared memory Neural nets

28. © P. H. Welch28 lex line.parse structure.parse source tokens l.tokens s.tokens.0 s.tokens.1 code.generate semantic.consistency t.ident ident q.token mess name.table error.reporter a.ident compiler errors object

29. © P. H. Welch29 PROC compiler (CHAN OF BYTE source, errors, CHAN OF CODE object) CHAN OF CODE object) CHAN OF INT tokens, t.ident: CHAN OF INT tokens, t.ident: CHAN OF SYNTAX s.tokens.0, s.tokens.1: CHAN OF SYNTAX s.tokens.0, s.tokens.1: CHAN OF INT q.token: CHAN OF INT q.token: CHAN OF STRING ident, a.ident: CHAN OF STRING ident, a.ident: CHAN OF ERROR mess: CHAN OF ERROR mess: PAR PAR lex (source, tokens, ident, t.ident) lex (source, tokens, ident, t.ident) parse (tokens, s.tokens.0) parse (tokens, s.tokens.0) semantic.consistency (s.tokens.0, s.tokens.1, mess) semantic.consistency (s.tokens.0, s.tokens.1, mess) code.generate (s.tokens.1, object) code.generate (s.tokens.1, object) name.table (ident, t.ident, q.token, a.ident) name.table (ident, t.ident, q.token, a.ident) error.reporter (mess, q.token, a.ident, errors) error.reporter (mess, q.token, a.ident, errors):

30. © P. H. Welch30 Support Environment Terminal Handler Editor Tool-1Tool-0Tool-2 File Handler

31. © P. H. Welch31 Fuzzy Logic 0 -100 +100 don't knowunlikelyprobable minimum maximumnegate

32. © P. H. Welch32 Bayesian Logic  chokes integrator influences (lower) opinions (higher) opinion   F0 F1 F2

33. © P. H. Welch33 The car is difficult to start It is difficult to rev the engine There is a grey deposit on the spark plugs There is a lack of power The fuel consumption is heavy The exhaust is smoky The car is backfiring The car has done a very high mileage Fuel jets were cleaned with wire The engine overheats Fuel is not reaching the engine Fuel is reaching the float chamber Fuel is reaching carburettor inlet Fuel is reaching the fuel pump Carburettor start jet is blocked Carburettor main jets are blocked Weak mix due to incorrect adjustment Rich mix due to incorrect adjustment Fuel pump is faulty Fuel jets have become enlarged Pipe from pump to float chamber is blocked Pipe from pump to tank is blocked Needle valve in float chamber is faulty Carburettor fuel mix is too weak Carburettor fuel mix is too rich High fuel level in float chamber

34. © P. H. Welch34 PROTOCOL COMPLEX64 IS REAL64; REAL64: PROC bfly (VAL REAL64 wr, wi, CHAN OF COMPLEX64 a, b, x, y) WHILE TRUE WHILE TRUE REAL64 ar, ai, br, bi: REAL64 ar, ai, br, bi: SEQ SEQ PAR PAR a ? ar; ai a ? ar; ai b ? br; bi b ? br; bi PAR PAR x ! ar + br; ai + bi x ! ar + br; ai + bi y ! (wr * (ar-br)) – (wi * (ai–bi)); y ! (wr * (ar-br)) – (wi * (ai–bi)); (wr * (ai-bi)) – (wi * (ar–br)) (wr * (ai-bi)) – (wi * (ar–br)): a b x y

35. © P. H. Welch35 8-Point FFT (Constant Geometry)

36. © P. H. Welch36 8-Point FFT (Constant Geometry) 00 10 20 30 40 50 60 70 01 11 21 31 41 51 61 71 02 12 22 32 42 52 62 72 03 13 23 33 43 53 63 73

37. © P. H. Welch37 VAL REAL64 zero IS 0.0: VAL [4][3]REAL64 real.weight IS [[zero, zero, zero], [1.0, zero, zero], [1.0, zero, zero], [2.0, 2.0, zero], [2.0, 2.0, zero], [3.0, 2.0, zero]]: [3.0, 2.0, zero]]: [8][4]CHAN OF COMPLEX64 c: PAR i = 0 FOR 4 PAR j = 0 FOR 3 PAR j = 0 FOR 3 bfly (real.weight[i][j], zero, c[i][j], bfly (real.weight[i][j], zero, c[i][j], c[i + 4][j], c[i + 4][j], c[2 * i][j + 1], c[2 * i][j + 1], c[(2 * i) + 1][j + 1]) c[(2 * i) + 1][j + 1]) 8-Point FFT (Constant Geometry)

38. © P. H. Welch38 Parallel Computation on Global Data Structures Shared Memory! X = (X 0, X 1, X 2,..., X i,..., X n-1 ) X’ = (X’ 0, X’ 1, X’ 2,..., X’ i,..., X’ n-1 ) Each component can be updated independently, but requires knowledge of the whole structure: X’ i = P i (X 0,..., X n-1 ) modelling (e.g. “n-body”) iterative numerics (e.g. Gauss-Jacobi)

39. © P. H. Welch39 Global Data X... P1P1 P n-1 P0P0

40. © P. H. Welch40 Global Data X... XP0XP0 XP1XP1 X P n-1 XXX... broadcast global data

41. © P. H. Welch41 Global Data X X’... X’ 1 X P 1 X’ n-1 X P n-1 X X... broadcast global data return updated components X’ 0 X P 0 X’ n-1 X’ 1 X’ 0 X...

42. © P. H. Welch42 This scheme is not directly implementable! For the correct mechanism, see the “n-body” problem and “geometric distribution” in Chapter 2

43. © P. H. Welch43 Neural Networks

44. © P. H. Welch44 Neural Networks In the neural net example, each node computes a weighted sum of the data held by all nodes in the layer above. In each layer, compute these “global” sums for each node and then drop the answers down to the next layer. Use a ring mechanism in each layer to broadcast and compute on this data in parallel.

45. © P. H. Welch45 Neural Networks

46. © P. H. Welch46 Neural Networks

47. © P. H. Welch47 The Dining Philosophers Once upon a time, five philosophers lived in the same college. They were proud, independent philosophers who though independent thoughts and never communicated with each other what these thoughts might have been. From time to time, each philosopher would get hungry. He/she would then stop thinking and go to the single dining room in the college – this had to be shared by all the philosophers.

48. © P. H. Welch48 The dining room contained one circular table, around which were symmetrically placed five chairs. Each chair was labelled with the name of one of the philosophers and each philosopher was only allowed to sit in her/his own chair. Opposite each chair was a plate and, on the left, was laid a golden fork. In the centre of the table was a large bowl of spaghetti, which was constantly replenished. F4F4 F3F3 F2F2 F1F1 F0F0 P0P0 P1P1 P2P2 P3P3 P4P4

49. © P. H. Welch49 The philosophers never managed to master the art of serving, or indeed, eating the spaghetti with a single fork. Consequently, they always tried to pick up both forks on either side of their plates. If a fork was being used by a neighbouring philosopher, the hungry philosopher politely waited for the neighbour to finish eating. This was the only occasion when the existence of one philosopher had an impact on another!

50. © P. H. Welch50 The philosophers lived like this for years and years until, one day, something most unfortunate happened. By chance, all the philosophers got hungry at the same time, went to the dining room, sat down and reached for the forks. By further chance, each philosopher picked up the fork on his/her left. Noticing that the other fork was being used, each philosopher waited for the neighbour to finish. And waited... and waited …... and starved to death! MORAL: philosophers ought to talk to each other a bit more

51. © P. H. Welch51 philosopher right left PROC philosopher (CHAN OF BOOL left, right) WHILE TRUE WHILE TRUE SEQ SEQ... think... think PAR -- pick up forks PAR -- pick up forks left ! TRUE left ! TRUE right ! TRUE right ! TRUE... eat... eat PAR -- put down forks PAR -- put down forks left ! TRUE left ! TRUE right ! TRUE right ! TRUE: The philosopher’s only point of contact with the rest of the world is when picking up and replacing the forks … he/she might find one or both not there … from which the presence of others may be deduced!

52. © P. H. Welch52 fork left right PROC fork (CHAN OF BOOL left, right) WHILE TRUE WHILE TRUE BOOL any: BOOL any: ALT ALT left ? any -- p.left picks up left ? any -- p.left picks up left ? any -- p.left puts down left ? any -- p.left puts down right ? any -- p.right picks up right ? any -- p.right picks up right ? any -- p.right puts down right ? any -- p.right puts down: Once a fork has been “picked up” by a philosopher (say on its left), it waits to be “put down” by that philosopher (i.e., on its left) and cannot be “picked up” by the other philosopher in the meantime. Note: fork is a binary semaphore

53. © P. H. Welch53 college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF

54. © P. H. Welch54 PROC college () [5] CHAN OF BOOL left, right: [5] CHAN OF BOOL left, right: PAR i = 0 FOR 5 PAR i = 0 FOR 5 PAR PAR philosopher (left[i], right[i]) philosopher (left[i], right[i]) fork (left[i], right[(i+1)\5]) fork (left[i], right[(i+1)\5]):

55. © P. H. Welch55 1.Buy one extra fork: The philosophers are very jealous and would not tolerate one of their number having more resources (e.g., a private fork) than the others! 2.Buy five extra forks: Too expensive! The college is suffering from government cut-backs and the forks are made of gold!! 3.One of the philosophers picks up the right fork first: Asymmetric solution. The philosophers do not talk to each other so it is difficult to arrange! Cannot impose decision because of jealously problem!! Ways to avoid this deadlock...

56. © P. H. Welch56 4.External authority: security College hires a security guard to whom each philosopher has to report when she wants to sit down at or stand up from the table. security The security guard has instructions not to allow more than four philosophers at a time to sit down. This solution is acceptable because it is symmetric (the philosophers still have equal, though reduced, rights) and is cheap (salaries are peanuts compared with the cost of extra forks). Ways to avoid this deadlock...

57. © P. H. Welch57 secure. college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF u[0]d[0] u[1] d[1] u[2] d[2]u[3] d[3] d[4] u[4] security

58. © P. H. Welch58 philosopher right left down up PROC philosopher (CHAN OF BOOL left, right, down, up) WHILE TRUE WHILE TRUE SEQ SEQ... think... think down ! TRUE -- get permission to sit down ! TRUE -- get permission to sit PAR -- pick up forks PAR -- pick up forks left ! TRUE left ! TRUE right ! TRUE right ! TRUE... eat... eat PAR -- put down forks PAR -- put down forks left ! TRUE left ! TRUE right ! TRUE right ! TRUE up ! TRUE -- notify security that up ! TRUE -- notify security that -- you have finished -- you have finished:

59. © P. H. Welch59 PROC security ([]CHAN OF BOOL down, up) VAL INT max IS 4: VAL INT max IS 4: INT n.sat.down: INT n.sat.down: SEQ SEQ n.sat.down := 0 n.sat.down := 0 WHILE TRUE WHILE TRUE BOOL any: BOOL any: ALT i = 0 FOR 5 ALT i = 0 FOR 5 ALT ALT (n.sat.down < max) & down[i] ? any (n.sat.down < max) & down[i] ? any n.sat.down := n.sat.down + 1 n.sat.down := n.sat.down + 1 up[i] ? any up[i] ? any n.sat.down := n.sat.down – 1 n.sat.down := n.sat.down – 1: security u[0]d[0] u[1] d[1] u[2] d[2] u[3] d[3] d[4] u[4]

60. © P. H. Welch60 secure. college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF u[0]d[0] u[1] d[1] u[2] d[2]u[3] d[3] d[4] u[4] security

61. © P. H. Welch61 PROC secure.college () [5]CHAN OF BOOL left, right: [5]CHAN OF BOOL left, right: [5]CHAN OF BOOL up, down: [5]CHAN OF BOOL up, down: PAR PAR security (down, up) security (down, up) PAR i = 0 FOR 5 PAR i = 0 FOR 5 PAR PAR philosopher (left[i], right[i], philosopher (left[i], right[i], down[i], up[i]) down[i], up[i]) fork (left[i], right [(i+1)\5]) fork (left[i], right [(i+1)\5]):

62. © P. H. Welch62 college The potential for deadlock in college was not obvious to its designers. The claim that there is no such potential within secure.college secure.college should not be accepted lightly. VERIFY We must provide a formal proof of the absence of deadlock in any safety- critical application. Systematic validation through “exhaustive” testing in unacceptable!

63. © P. H. Welch63 Lemma: a deadlocked network will contain a cycle of processes with each process in the cycle blocked trying to communicate with the next node in the cycle. DEF (informal): DEADLOCK A network of processes is deadlocked when every process is blocked trying to communicate with other processes within that network. If any process within the network is blocked on an external communication, it is willing to accept that external communication – and the network is not deadlocked. A deadlocked network refuses all external communications.

64. © P. H. Welch64 If any process within the network is blocked on a timeout, that process will eventually continue – and the network is not deadlocked. A network of processes is deadlocked when every process is blocked trying to communicate with other processes within that network. DEF (informal): DEADLOCK

65. © P. H. Welch65 college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF !!!!!! !! !! ?? ?? ?? ???? This college may deadlock  Note the cycle of blocked communications

66. © P. H. Welch66 secure. college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF u[0]d[0] u[1] d[1] u[2] d[2]u[3] d[3] d[4] u[4] security What about this one?

67. © P. H. Welch67 The claim that there is no such potential within secure.college secure.college should not be accepted lightly. ASSUME: secure.college is deadlocked … In that case, all its processes – each philosopher, each fork and the security guard are blocked. Where might they be? The security guard can only be in one place – blocked on its ALT, waiting for a philosopher to enter/leave the dining room. Each fork is either on the table or in the hands of one of its neighbouring philosophers.

68. © P. H. Welch68 The claim that there is no such potential within secure.college secure.college should not be accepted lightly. ASSUME: secure.college is deadlocked … In that case, all its processes – each philosopher, each fork and the security guard are blocked. Where might they be? Each philosopher could be in one of several places – thinking, trying to get past security, trying to pick up its forks, eating, trying to put down its forks or trying to leave the dining room (i.e. telling security that it’s leaving).

69. © P. H. Welch69 PROC philosopher (CHAN OF BOOL left, right, down, up) WHILE TRUE WHILE TRUE SEQ SEQ... think... think down ! TRUE -- get permission to sit down ! TRUE -- get permission to sit PAR -- pick up forks PAR -- pick up forks left ! TRUE left ! TRUE right ! TRUE right ! TRUE... eat... eat PAR -- put down forks PAR -- put down forks left ! TRUE left ! TRUE right ! TRUE right ! TRUE up ! TRUE -- notify security that up ! TRUE -- notify security that -- you have finished -- you have finished: Can’t get stuck here! philosopher right left down up Four must get past here …

70. © P. H. Welch70 The claim that there is no such potential within secure.college secure.college should not be accepted lightly. ASSUME: secure.college is deadlocked … In that case, all its processes – each philosopher, each fork and the security guard are blocked. Where might they be? Therefore, one philosopher must be stuck trying to get past security. The other four must be in the dining room, trying to pick up their forks. No philosopher can have picked up both forks.

71. © P. H. Welch71 secure. college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF u[0]d[0] u[1] d[1] u[2] d[2]u[3] d[3] d[4] u[4] security Suppose the top philosopher is not at the table P P PP

72. © P. H. Welch72 secure. college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF u[0]d[0] u[1] d[1] u[2] d[2]u[3] d[3] d[4] u[4] security P P PP Philosophers 1 and 4 must get the top forks forkfork Philosophers 1 and 4 can’t get their other forks

73. © P. H. Welch73 secure. college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF u[0]d[0] u[1] d[1] u[2] d[2]u[3] d[3] d[4] u[4] security P P PP Philosophers 2 and 3 must have them … forkfork Philosophers 2 and 3 can’t get their other forks forkfork

74. © P. H. Welch74 secure. college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] P P PP P F F F FF u[0]d[0] u[1] d[1] u[2] d[2]u[3] d[3] d[4] u[4] security P P PP But one of them will … forkfork Philosophers 2 and 3 can’t get their other forks forkfork CONTRADICTION: the initial assumption (of deadlock) is impossible !!! Q.E.D Q.E.D fork

75. © P. H. Welch75 Exercise: secure.college Provide some links from secure.college to the outside world and animate an interactive demonstration of life inside. fork Modify the fork process so that it guarantees service on each input – even if the other one is perpetually busy. No philosopher must starve because of greedy colleagues!

76. © P. H. Welch76 reporting. college r[0] l[0] l[4] l[3] l[2] l[1] r[4] r[3] r[2] r[1] u[0]d[0] u[1] d[1] u[2] d[2]u[3] d[3] d[4] u[4] PPPP P FFFFF security

77. © P. H. Welch77 Systolic Arrays Multiplication of two arrays is a common operation in computational engineering: Assume we have: an array B which is m  n and : an array C which is n  l and we want: A = B*C. Then, A[i][j] is equal to the sum for k = 0 to n-1 of B[i][k] * C[k][j]

78. © P. H. Welch78 PROC node (VAL INT n, CHAN OF REAL64 hl, hr, vu, vd ) CHAN OF REAL64 hl, hr, vu, vd ) REAL64 sum: REAL64 sum: SEQ SEQ sum := 0.0 sum := 0.0 SEQ k = 0 FOR n SEQ k = 0 FOR n REAL64 x, y: REAL64 x, y: SEQ SEQ PAR PAR hl ? x hl ? x vu ? y vu ? y PAR PAR sum := sum + (x * y) sum := sum + (x * y) hr ! x hr ! x vr ! y vr ! y: The array multiplication can be carried out rapidly with multiple copies of the following module: hl vd vu hr node

79. © P. H. Welch79 Systolic Arrays We create a systolic array of the nodes, and pump the elements of B and C through:...... a 03 a 02 a 01 a 00... a 12 a 11 a 10 0... a 21 a 20 0 0... a 30 0 0 0... b 30 b 20 b 10 b 00... b 21 b 11 b 01 0... b 12 b 02 0... b 03 0

80. © P. H. Welch80 Systolic Arrays If the array of nodes is implemented in a VLSI device, all nodes can be executing at the same time. After about n steps, each node ( i, j ) will contain A i,j ; this is considerably faster than the m  n  l steps that would be required if you did each operation sequentially. Exercise: Develop a complete program, using the basic node, to carry out a matrix multiplication. Options: leave the computed elements in the nodes move the complete elements to the edge of the array