Dining Philosophers:

A Classic Parallel
Processing Problem

by E Dijkstra

Presented by:

Monzur Morshed
Habibur Rahman

TigerHATS
www.tigerhats.org
TigerHATS - Information is power

The International Research group dedicated to Theories, Simulation and

Modeling, New Approaches, Applications, Experiences, Development,
Evaluations, Education, Human, Cultural and Industrial Technology
 Dining Philosophers (1)

 Philosophers eat/think
 Eating needs 2 forks
 Pick one fork at a time
 How to prevent
deadlock

3
 Definition
 Extension to mutual exclusion
 Arbitrary topology
 Each philosopher (process)
proceeds through the following
cycle
• Thinking may
remain indefinitely
• Hungry
• Eating has to finish within finite
time

 Solution properties
• Safety – no two neighbors
eat at the same time
• Liveness – each hungry
philosopher eventually eats
 Problem Statement
 Five philosophers eat then think forever
• They never sleep nor relieve themselves!
• They do not behave altruistically
 They eat at a communal table
• It has a single bowl of tangled spaghetti
• Five plates each with a single fork to the left of their
plate
• To eat a philosopher must have two forks, their own
and that of their neighbour’s to the right
• If a philosopher is unable to eat they resume thinking
 Ramifications
 Deadlock
• All philosophers decide to eat at same time
• They all pick up one fork
• None of them can eat hence the system comes to a halt
• Circular waiting for resources
 Starvation
• Some philosophers think for such a short time and contrive
to put their forks down in such a way that no other
philosophers have the opportunity to pick up the two forks
they require to eat
• Thread waits indefinitely
 Livelock
• A policy that makes them all do something endlessly
without ever eating!
 Deadlock  Starvation but not vice versa
• Starvation can end (but doesn’t have to)
• Deadlock can’t end without external intervention
Dining Philosopher’s Problem
(Dijkstra ’71)
Deadlock - Pictorially
Starvation - Pictorially
 A Different Formulation
 Philosophers go the canteen for their food
 They form a queue outside the canteen

 A Chef brings chickens to the canteen in

batches that are less than the number of
philosophers
 Philosophers connected to Canteen by
means of Any channels
 Behaviour
 Philosophers go hungry
• They can get into the canteen even when there
are no chickens
• Need to ensure that philosophers queue until
chickens available
 Only the Canteen process needs to be
modified
• Simply needs a precondition on the ALT
Dining Philosopher Problem (Dijkstra’71)
Philosopher i
 5 philosophers, 5
chopsticks while (true) {
//think for a while, getting hungry
chopstick[i].P();
 Use 5 semaphores, one chopstick[(i+1) % 5].P();
for each chopstick: //eat now; (critical section)
• Chopstick[1..5] chopstick[i].V();
chopstick[(i+1) % 5].V();
}
 What is deadlock?
 When some system processes are blocked on
resource requests that can never be satisfied
unless drastic actions are taken, the processes
are deadlocked.
 Three approaches to deadlock
• Prevent deadlock by careful system analysis
• Detect deadlock when it happens, and take
corrective action
• Ignore the problem and hope for the best (this is
the Unix and Windows model)
 Causes of Deadlock
 Strict deadlock is caused by cyclic resource
requests
 Effective deadlock is caused by resource
depletion (for example, not enough
memory to run a large process thread)
Thread
Wait
Owned A
For
By
Res 1 Res 2
Owned
Wait Thread By
For B
 The Danger of Deadlock
philosopher 1 philosopher 2 philosopher 3 philosopher 4 philosopher 5
cstick[1].P(); cstick[2].P(); cstick[3].P(); cstick[4].P(); cstick[5].P();
cstick[2].P(); cstick[3].P(); cstick[4].P(); cstick[5].P(); cstick[1].P();

 It is possible for all processes to block

• Deadlock !
cstick[1]

cstick[5] cstick[2]

cstick[4] cstick[3]
 Avoiding Deadlock(1)
philosopher 1 philosopher 2 philosopher 3 philosopher 4 philosopher 5
cstick[1].P(); cstick[2].P(); cstick[3].P(); cstick[4].P(); cstick[1].P();
cstick[2].P(); cstick[3].P(); cstick[4].P(); cstick[5].P(); cstick[5].P();

 Avoid cycles (or have a total ordering of

the chopsticks)
cstick[1]

cstick[5] cstick[2]

cstick[4] cstick[3]
Necessary Conditions for Deadlock

 Mutual exclusion
 Hold and wait condition

 No preemption condition

 Circular wait condition

 Original scenario & our proposed ritual

had all four of these properties.
Necessary Conditions for Deadlock
 Mutual exclusion
• Exclusive use of chopsticks
 Hold and wait condition
• Hold 1 chopstick, wait for next
 No preemption condition
• Cannot force another to release held resource
 Circular wait condition
• Each waits for next neighbor to put down chopstick
 Critical Regions(1)
 Four conditions to provide mutual
exclusion
• No two processes simultaneously in critical
region
• No assumptions made about speeds or
numbers of CPUs
• No process running outside its critical region
may block another process
• No process must wait forever to enter its
critical region
 Critical Regions(2)

Mutual exclusion using critical regions

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
 Dining Philosophers: Solutions
 Waiter solution
• Since the philosophers don't speak with each other
• One solution is to have them speak to a waiter which keeps an
overview of the table, he can then decide who gets forks and
when.

 Resource hierarchy solution

• Resource hierarchy consists of ordering the forks by number.
• It always be requested by order and released in the reverse order.

 Chandy / Misra solution

• The forks as either being clean or dirty and based on this
categorization the philosophers requests the forks from one
another.
• It request equals communication and so the restraint inherent to
the problem has been violated - So this is really no solution at all.
 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
 Semaphore solution
 A semaphore is a variable or abstract data type
 Semaphores are used for synchronization and
mutual exclusion by indicating the availability and
number of resources.
 The pthread package provides two types of
semaphores – named and unnamed.
 For this project, we use unnamed or Binary
semaphores.
 Binary semaphore –integer value can range only
between 0 and 1; can be simpler to implement
 Semaphore solution
 The code below illustrates how a semaphore is
created:
#include <semaphore.h>
sem_t mutex; /* create the semaphore and initialize it to 1 */
sem_init(&mutex, 0, 1);
sem_wait(&mutex); /* acquire the semaphore */
/*** critical section ***/
sem_post(&mutex); /* release the semaphore */

The sem_init(…) creates a semaphore and initialize it. This function is passed three
parameters:
1. A pointer to the semaphore
2. A flag indicating the level of sharing ( flag o indicating that this semaphore can
only be shared by threads belonging to the same process that created the
semaphore. A nonzero value would allow other processes to access the
semaphore as well.
3. The semaphore’s initial value (1)
Dining Philosophers(Source Code)

Solution to dining philosophers problem (part 1)

Dining Philosophers(Source Code)
Running the code
Thank You 