1. Termination Detection Part 1

2. Goal Study the development of a protocol for termination detection with the help of invariants.

3. Termination Detection Rules: –A process is either active or passive –An active process can become passive at any time –A passive process can become active only if it receives an computation message –Only active processes can send computation messages. All processes can receive them –Any process can send control messages, I.e., messages sent for detecting termination

4. A system is said to be terminated if –All processes are passive –No computation messages are in transit Reminder: We distinguish between computation messages and messages sent for detecting termination. Any process can send and receive them. These messages do not change the status of a process

5. Application A solution for termination detection allows one to ensure that all tasks in a system are indeed complete, even though the tasks may create additional tasks that are run at other processors in the system

6. Observation Termination detection is a stable property –Once true, it remains true forever Detecting such properties is important for many problems including –Garbage collection –Deadlock detection

7. We will consider two algorithms Based on the idea of diffusion Based on the idea of global snapshot –We will study these aspects later.

8. Approach 1: Dijkstra Scholten Assumptions –Initially one process is active –No failures, lost messages etc.

9. Each process j maintains a variable P.j that is its parent in the tree –At root, P.root = root –Initially for all other processes, P.j = NULL

10. Predicate in Invariant (1) The set of active processes form a tree –True in the initial state –Ensure that this remains true during computation

11. When a Process becomes active Consider the case when j changes from Passive to Active –It must be the case that j received a computation message from some process, say k P.j = k Become active

12. Action (1) P.j = NULL  j receives a message from k  P.j = k, j becomes active

13. When a Process Becomes Passive Consider the case when j changes from Active to Passive –It must be the case that j has no children

14. Action (2) P.j = NULL  j receives a message from k  P.j = k, j becomes active j is active  j wants to become passive  j has no children  j becomes passive, P.j = NULL

15. Alternatives J is active  J is passive and for all children of j –Set their parent to P.j –Or set their parent to root There are some paeprs with this idea. But we will skip them here

16. Problem? Does not deal with messages.

17. Predicate in Invariant (2) The set of active processes form a tree If j is passive then all messages it sent have been received –True initially –Preserve this predicate during computation

18. Action (3) Maintain a variable oc.j that denotes the number of messages that j has sent and are not yet acknowledged

19. Action (2) corrected P.j = NULL  j receives a message from k  P.j = k, j becomes active j is active  j wants to become passive  j has no children  oc.j = 0  j becomes passive, P.j = NULL

20. The actions on previous slide can be used to implement termination detection. Consider second action j is active  j wants to become passive  j has no children  oc.j = 0  j becomes passive, P.j = NULL Is it possible to drop ` j has no children’ from the guard?

21. Answer We could if we guarantee that –oc.j = 0  j has no children –Same as j has children  oc.j > 0 Could be achieved if the child does not respond to at least one of parent’s message (first one?) Thus, checking oc.j is 0 sufficient

22. Action (3) P.j = NULL  j receives a message from k  P.j = k, j becomes active (Don’t send ack to this message) j is active  j wants to become passive  oc.j = 0  j becomes passive, P.j = NULL; send ack to parent j is active  j receives a message from k  Send ack to k Other simple actions for maintaining oc.j

23. Summarizing Approach 1 Goal –Active processes form a rooted tree If process k activates j then j sets its parent to k –If a process is passive, all messages it sent have been received Acknowledge each message (at some time) –A process becomes passive only when all its children are passive; in other words, force a process to wait for its children to become passive. This is achieved if the children do not send an acknowledgment for the first message received from the parent until they become passive.

24. Actions Passive  Active –If j is passive and receives a computation message from k then P.j = k Become active

25. Actions Active  Active –If j is active and receives a computation message from l Send an acknowledgment

26. Actions Message send –If j wants to send message (it must be active) oc.j ++ (Number of outstanding acknowledgments is increased) Acknowledgement receive –oc.j = oc.j – 1

27. Actions Active  passive –If j wants to be passive and oc.j = 0 Send an acknowledgment to P.j (Observe that the first message from parent was not immediately acknowledged) Become passive If j is the root then declare termination

28. Diffusing Computation Crucial for various applications General outline –root(?) sends the diffusion message –Every node that receives the diffusion message for the first time forwards it to its neighbors First node from which diffusion is received is called parent –All subsequent diffusion messages are acknowledged –Upon receiving acknowledgements form all neighbors, a node completes the diffusion and sends acknowledgment to parent –When root completes the diffusion, the diffusion computation is complete

29. Termination Detection II

30. Approach Arrange processes in a (hypothetical) ring –The ring is used only for the sake of termination detection –Any process can communicate with any other process

31. Approach Each process maintains a variable c.j c.j = number of messages sent by j – number of messages received by j Initially, c values are all 0

32. Action (1) When j wants to sent a message c.j := c.j + 1 When j receives a message c.j := c.j – 1

33. Observation Number of messages in transit = Detect the value of Ensure that when c.j is read j is passive

34. Action (2) Send a token along the ring to compute When 0 sends a token (token is sent only when the previous token is received and process 0 is passive) token.sum = c.0 Forwarding the token by process j, j <> 0 (token is sent only when j is passive) token.sum := token.sum + c.j

35. Remark Observe that the token is taking a snapshot of the system –The global snapshot consists of local snapshot of every process

36. Invariant (1) P1 = (token is between k and k+1  ((token.sum = c.0 + c.1 + c.2 + … + c.k) /\ (processes 0..k are passive))

37. If P1 were true and the toekn is between n and 0 then token.sum would capture the sum of c values and all processes would be passive

38. Problem with P1 After a token is sent by k, some process in the range 0..k may receive a message, thereby violating P1 To deal with this, we have two options –Strengthen P1 so that such a message cannot be received –Weaken P1 so that the invariant contains states that are reached due to such messages We need to follow this approach

39. Question What can be said of states reached due to violation of P1

40. Invariant (2) P1 \/ P2, where P2 = (token is between k and k+1  (token.sum + c.(k+1) + c.(k+2) … + c.n > 0) If we start from a state where P1 is true and P1 becomes false then in that state P2 is true

41. Problem with P1 \/ P2 Consider the case where the token is between k and k+1 Some process, j, j < k, is active j sends a message to a process l, l > k –In this scenario, we want to make sure that l invalidates the token circulation so that process 0 ignores token.sum

42. Introduce a color for process When j receives a message c.j := c.j – 1; color.j := purple // Addition to previous action

43. Invariant (3) P1 \/ P2 \/ P3, where P3 = (token is between k and k+1   l : l > k : color.l = purple)

44. Problem Consider the case where l is purple and intends to ensure that the token circulation is invalidated –What happens if l forwards the token –All predicates P1, P2, P3 can be false. Also, the color needs to be changed back to yellow so that the token circulation will be eventually valid

45. Solution Introduce a color.token –Initially yellow Forwarding the token by process j, j <> 0 (remember: token is sent only when j is passive) token.sum := token.sum + c.j if (color.j = purple) color.token = purple color.j = yellow else // Preserve the token color that you received. // Basically, do nothing.

46. Invariant (4) P1 \/ P2 \/ P3 \/ P4, where P4 = color.token = purple

47. When Should color.token be reset? At process 0? –Is P1 \/ P2 \/ P3 \/ P4 violated in such circumstances? If no, which of these predicates is guaranteed to be true

48. When is Termination Detected? Token returns to 0 color.token = yellow, and token.sum = 0

49. Can we Deduce Termination from Invariant? How?