Вы находитесь на странице: 1из 11

CS 603 Dining Philosophers Problem

February 15, 2002

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

Dining Philosophers Problem (Dijkstra 71)

Dining Philosophers: Solutions


Simple: waiting state
Enter waiting state when neighbors eating When neighbors done, get forks Neighbors cant enter waiting state if neighbor waiting

Problem:
Doesnt prevent starvation Requires checking both neighbors at once
Race condition

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
Cant just hold the fork indefinitely

Communication only between adjacent philosophers


No global state Cant communicate with both at same time

No Deterministic Solution
Proof: Assume solution for philosophers 1..n
Philosophers dont 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!

Probabilistic Solution
Assume Random coin toss
Guaranteed with probability 1 to break symmetry Think trying = true or die While trying s = random(left,right) Wait for fork s then take it If fork ~s available take it else drop fork s Eat drop s=random(left,right) drop fork ~s

Idea: Try to get one first


Then get other If cant get other, put first down and try again

But dont go for the same fork first every time

Lemmas: Assume Plato sitting to left of Aristotle


1.

If Plato picks up fork infinite number of times, Aristotle finite number, then
P(Plato eats infinite number of times)=1

2. 3.

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 u ,
One picks up fork only finite number of times in future, or One gets to eat in next two draws

4.

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

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

Problem: Not Lockout-free Courteous Philosophers


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 or s-last = neutral or s-last = s) then lift fork s If ~s down then lift ~s; trying = false else drop s Eat left-signal = right-signal = off left-last = right; right-last = left Drop forks

Lesson: Non-Determinism Gives Additional Power


In fully distributed system, random variable solves problems that cant otherwise be solved Used in practice
Ethernet: Random backoff if collision

Makes proving correctness harder Consider such solutions when building distributed systems!

Вам также может понравиться