Dining Philosopher's Problem

DINING PHILOSOPHER’S PROBLEM

© Yash Mittal 1

THE PROBLEMThe Scenario- 5 silent philosophers sit at a round table with 5 bowls of

spaghetti- A fork is placed between each pair of adjacent philosophers- Eating is NOT limited by amount of spaghetti left: infinite

supply assumed

The Rules- Each philosopher must ‘alternately’ think and eat- A philosopher can only eat spaghetti when he has both left

and right forks- Each fork can be held by only 1 philosopher- After eating, he needs to put down both forks so they

become available to others- A philosopher can grab the fork on left or right as they

become available→ He can’t start eating until he has both of them

© Yash Mittal 2

PROBLEMSHow to design a Concurrent Algorithm such that each philosopher won’t starve, i.e., he can forever continue to alternate between eating and thinking assuming that any philosopher cannot know when others may want to eat or think.

The problem was designed to illustrate the challenges of avoiding Deadlock – a system state in which no progress is possible.

Resource Starvation- A problem encountered in multitasking where a process is perpetually denied necessary

resources. Without them the process can never finish its task,- Resource Starvation might occur independently if a particular philosopher is unable to acquire

both forks because of a timing problem.

Mutual Exclusion- Ensuring that no 2 concurrent processes are in their critical section at the same time.- A basic requirement in Concurrency Control to prevent race conditions.

© Yash Mittal 3

SOLUTIONSResource Hierarchy Solution- Assigns a partial order to the resources (forks)- All resources will be requested in order & no 2 resources unrelated by order

will ever be used by a single unit of work at the same time.- Resources are numbered 1-5 and each philosopher will always pick up the

lower-numbered fork first and then the higher-numbered fork.- If 4 of 5 philosophers simultaneously pick up their ‘low fork’, only 1 ‘high fork’

will remain on the table. So the 5th philosopher will NOT be able to pick upany fork.

→ Also, only 1 philosopher will have access to the ‘high fork’ he will beable to eat using 2 forks

- Not always practical if list of required resources is not completely known inadvance.

© Yash Mittal 4

Arbitrator Solution

- Guarantee that a philosopher can pick up only 2 solutions by introducing anarbitrator, Ex: waiter.

→ In order to pick up the forks, a philosopher must ask waiter’spermission

→ Waiter gives permission to only 1 philosopher at a time until he haspicked up both his forks

→ Putting down a fork is always allowed.- Waiter is implemented as a mutex - a program object that allows multiple

program threads to share the same resource, such as file access, but notsimultaneously.

© Yash Mittal 5

Requirement EngineeringRequirements are of 2 types:i. Userii. System

a. Functional Requirementsb. Non-Functional Requirementsc. Domain Requirements

Process of identification of requirements is called Requirement Engineering.

Four phases1. Requirement Discovery2. Requirement Analysis3. Requirement Validation4. Requirement Management

© Yash Mittal 6

Requirement Discovery Phase

Scenario – based Modelling

Use Case Diagram– Actor : Philosophers– Use Cases : Thinking, Eating, Acquiring Resources (forks)

Composition of Scenario [EATING]– Pre-Condition : Resources (forks) available– Normal Flow : Philosopher 2 forks available Eating spaghetti

Finished Put down forks Thinking– Abnormal Flow : Philosopher is eating

Another philosopher avails resources (Deadlock)– Other Activity : Resource is not available Philosopher thinks– Post-Condition : Free the resources (forks are available)

© Yash Mittal 7

Requirement Analysis Phase3 Types of Modellingi. Class/Object Modelsii. Flow Oriented Modelsiii. Behaviour Models

Flow Oriented Models – Data Flow Diagrams

DFD Level 0

© Yash Mittal 8

Dining Philosopher's Problem

Software

Transcript of Dining Philosopher's Problem