The document discusses the dining philosopher's problem, where five philosophers must alternately think and eat spaghetti using forks placed between them, illustrating challenges in concurrent algorithms like avoiding deadlock and resource starvation. It proposes solutions such as a resource hierarchy and an arbitrator (waiter) to manage fork access and ensure that philosophers can eat without starvation. Additionally, it covers requirements engineering, detailing discovery, analysis, validation, and management phases for functional and non-functional requirements.

1. DINING PHILOSOPHER’S
PROBLEM
© Yash Mittal 1

2. THE PROBLEM
The 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

3. PROBLEMS
How 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

4. SOLUTIONS
Resource 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 up
any fork.
→ Also, only 1 philosopher will have access to the ‘high fork’  he will be
able to eat using 2 forks
- Not always practical if list of required resources is not completely known in
advance.
© Yash Mittal 4

5. Arbitrator Solution
- Guarantee that a philosopher can pick up only 2 solutions by introducing an
arbitrator, Ex: waiter.
→ In order to pick up the forks, a philosopher must ask waiter’s
permission
→ Waiter gives permission to only 1 philosopher at a time until he has
picked 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 not
simultaneously.
© Yash Mittal 5

6. Requirement Engineering
Requirements are of 2 types:
i. User
ii. System
a. Functional Requirements
b. Non-Functional Requirements
c. Domain Requirements
Process of identification of requirements is called Requirement Engineering.
Four phases
1. Requirement Discovery
2. Requirement Analysis
3. Requirement Validation
4. Requirement Management
© Yash Mittal 6

7. 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

8. Requirement Analysis Phase
3 Types of Modelling
i. Class/Object Models
ii. Flow Oriented Models
iii. Behaviour Models
Flow Oriented Models – Data Flow Diagrams
DFD Level 0
© Yash Mittal 8

9. DFD Level 1
© Yash Mittal 9

10. Behaviour Modelling
 State Diagram
 Sequence Diagram
© Yash Mittal 10

11. THANK YOU
© Yash Mittal 11