CS 603 Dining Philosopher’s Problem

1. CS 603Dining Philosopher’s Problem February 15, 2002

2. Project 2 Starts Today • The winner: • NTP Client • Basic: Program that accepts NTP server as argument, gets and returns time from that server • Three points for well document and tested solution • Extras (worth one additional point): • Fault Tolerant averaging solution: Accepts up to four servers and gives average after throwing away “bad” servers • Class library: Initialize sets offset from local clock, “get time” returns local + offset without sending message

3. Dining Philosopher’s Problem(Dijkstra ’71)

4. Dining Philosophers: Solutions • Simple: “waiting” state • Enter waiting state when neighbors eating • When neighbors done, get forks • Neighbors can’t enter waiting state if neighbor waiting • Problem: • Doesn’t prevent starvation • Requires checking both neighbors at once • Race condition

5. Fully Distributed Solution(Lehman and Rabin ’81) • Problem with previous solutions • Not truly distributed: Requires some sort of central coordination or global state • Non-Symmetric: Different philosophers run different algorithms • Additional properties: • Deadlock free: Eventually someone new gets to eat • Lockout free: Eventually every hungry philosopher gets to eat • Adversary: One philosopher may try to starve another • Can’t just hold the fork indefinitely • Communication only between adjacent philosophers • No global state • Can’t communicate with both at same time

6. No Deterministic Solution • Proof: Assume solution for philosophers 1..n • Philosophers don’t know their number! • Philosophers “activated” in order from 1..n • Each takes one step • Claim: If symmetric at beginning of round, will be symmetric at end of round • If anyone eating, all would be!

7. Assume Random “coin toss” Guaranteed with probability 1 to break symmetry Idea: Try to get one first Then get other If can’t get other, put first down and try again But don’t go for the same fork first every time Think trying = true or die While trying s = random(left,right) Wait for fork s then take it If fork ~s available take itelse drop fork s Eat drop s=random(left,right) drop fork ~s Probabilistic Solution

8. Lemmas: Assume Plato sitting to left of Aristotle • If Plato picks up fork infinite number of times, Aristotle finite number, then • P(Plato eats infinite number of times)=1 • If deadlocked, every philosopher picks up fork infinite number of times with probability 1 • If after t steps, both trying to eat, tried to get same fork. Then with probability  ½, • One picks up fork only finite number of times in future, or • One gets to eat in next two draws • If at time t the last set of random draws is A, then with probability 1 there is a later configuration B ≠ A where two neighbors try to get the same fork first

9. Theorem: P(Deadlock) = 0 • Assume P(Deadlock) > 0 • By Lemma 2, if deadlocked everyone performs infinite draws • By Lemma 4, with probability 1 there will be infinite sequence of configuration of last draws A0, A1, … satisfying condition of Lemma 3 • By Lemma 3, n some philosopher eats between An and An+2 with probability 1 • Therefore if deadlocked, non-deadlocked condition will occur with probability 1

10. Possible for all but one to starve Solution: If eating and neighbor trying to eat, once done wait until neighbor has eaten before trying again Requires more shared variables “signal” to neighbor: On/Off Share “last” with neighbor: Left, Neutral, Right Initialized to Neutral Only need mutual exclusion with one neighbor at a time Think trying = true; left_signal = right_signal = on s = random(left,right) Wait until s down and(s-neighbor-signal = off ors-last = neutral or s-last = s)then lift fork s If ~s down thenlift ~s; trying = false else drop s Eat left-signal = right-signal = off left-last = right; right-last = left Drop forks Problem: Not Lockout-freeCourteous Philosophers

11. Lesson: Non-Determinism Gives Additional Power • In fully distributed system, random variable solves problems that can’t otherwise be solved • Used in practice • Ethernet: Random backoff if collision • Makes proving correctness harder Consider such solutions when building distributed systems!