Specifying distributed computation

1. Specifying distributed computation • Why do we need these? • Don’t we already know a lot about programming? • Well, you need to capture the notions of atomicity, non-determinism, fairnessetc. These concepts are not built into languages like JAVA, C++ etc!

2. Syntax & semantics: guarded actions Guarded action <guard G><action A> is equivalent to if G then A

3. Syntax & semantics: guarded actions Three types of constructs: • Sequential actions S0; S1; S2; . . . ; Sn • Alternative constructsif . . . . . . . . . . fi • Repetitive constructsdo . . . . . . . . . od The specification is useful for representing abstract algorithms, not executable codes.

4. Syntax & semantics Alternative construct if G0 S0  G1 S1  G2 S2 …  GnSn fi When no guard is true, skip (do nothing). When multiple guards are true, the choice of the action to be executed is completely arbitrary.

5. Syntax & semantics Repetitive construct do G1S1  G2 S2 .  Gn Sn od Keep executing the actions until all guards are false and the program terminates. When multiple guards are true, the choice of the action is arbitrary.

6. An example program uncertain; define x : integer; initially x = 0 do x < 4  x := x + 1  x = 3  x := 0 od Question. Will the program terminate? Here fairness becomes an important issue

7. Adversary Distributed computation can be viewed as a game between the system and an adversary. The adversary comes up with schedules to challenge the system.

8. Non-determinism Non-determinism is abundant in the real world. Determinism is a special case of non-determinism. (Program for a token server - it has a single token} repeat if (req1 and token) then give the token to client1 elseif (req2 and token) then give the token to client2 elseif (req3 and token) then give the token to client3 forever Now, assume that all three requests are sent simultaneously. Client 1 always gets the token!

9. Atomicity = all or nothing Atomicity = indivisible actions do red  x:= 0 {red action}  blue  x:=7 {blue action} od Regardless of how nondeterminism is handled, we would expect that the value of x will be an arbitrary sequence of 0's and 7's. Right or wrong? Atomicity (or granularity) x

10. Does hardware guarantee any form of atomicity? Yes! Transactions are atomic by definition (in spite of process failures). Also, critical section codes are atomic. We will assume that G  S is an atomic operation Atomicity (or granularity) if x ≠ y  y:= x fi x y if x ≠ y  y:= x fi

11. {Program for P} Define b: boolean initially b = true do b  send msg m to Q ¬empty(R,P) receive msg; b := false od Suppose it takes 15 seconds to send the message. After 5 seconds, P receives a message from R. Will it stop sending the remainder of the message? NO. Atomicity R P Q b

12. Fairness Defines the choices or restrictions on the scheduling of actions. • Unconditional fairness • Weak fairness • Strong fairness

13. Program test define x : integer {initial value unknown} do true  x : = 0  x = 0  x : = 1  x = 1  x : = 2 od An unfair schedulermay never schedule the second (or the third actions). So, x may always be equal to zero. An unconditionally fair scheduler will eventually give every statement a chance to execute without checking their eligibility. (Example: process scheduler in a multiprogrammed OS.) Fairness

14. Program test define x : integer {initial value unknown} do true  x : = 0  x = 0  x : = 1  x = 1  x : = 2 od A scheduler is weakly fair, when it eventually executes every guarded action whose guard becomes true, and remains true thereafter A weakly fair scheduler will eventually execute the second action, but may never execute the third action. Why? Weak fairness

15. Program test define x : integer {initial value unknown} do true  x : = 0  x = 0  x : = 1  x = 1  x : = 2 od A scheduler is strongly fair, when it eventually executes every guarded action whose guard is true infinitely often. The third statement will be executed under a strongly fair scheduler. Strong fairness