--- title: "Monitor; dining philosophers with semaphore" subject: "Operating System" chapter: 3 key: "semester_6/operating_system:monitor-dining-philosopher" source: https://www.bctengineer.com/q/semester_6/operating_system/monitor-dining-philosopher site: BCT Engineering --- # Monitor; dining philosophers with semaphore Operating System · Chapter 3: Process Communication and Synchronization - Asked in: 2068 Bhadra, 8 marks - Video: [OS 6. Monitors - Usage - Dining Philosophers solution - Implementation using semaphores](https://www.youtube.com/watch?v=bGs7ID-Ex0A) — Cracking Concepts by Kiran Mary Matthew - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_6/operating_system/monitor-dining-philosopher - Whole chapter: https://www.bctengineer.com/md/semester_6/operating_system/chapter-3 ## Question What is a monitor? Solve the dining philosopher's problem using semaphore. ## Short answer A monitor is a high-level module of procedures and data with automatic mutual exclusion; condition variables and wait/signal synchronize processes. The semaphore solution for dining philosophers uses a mutex, state array (thinking, hungry, eating) and per-philosopher semaphores; a philosopher eats only if neighbors are not eating, avoiding deadlock. ## Answer #### Monitor A **monitor** is a high-level synchronization construct: a package of procedures, variables and data structures, with the rule that **only one process may be active in the monitor at any instant**. The compiler adds the mutual exclusion automatically, so the programmer does not code locks. Inside it, **condition variables** with the operations `wait(c)` (block and release the monitor) and `signal(c)` (wake one waiting process) are used to synchronize processes. Example: producer-consumer with `insert()` and `remove()` procedures. #### Dining philosophers using semaphores Five philosophers alternate between thinking and eating; each needs the two forks beside him. A philosopher may eat only if neither neighbour is eating. The solution below uses an array `state[]`, a mutex for the critical regions, and one semaphore per philosopher on which he blocks when forks are not available. It avoids deadlock; neighbours are tested whenever forks are put down. ```c #define N 5 /* number of philosophers */ #define LEFT (i+N-1)%N /* left neighbour of i */ #define RIGHT (i+1)%N /* right neighbour of i */ #define THINKING 0 #define HUNGRY 1 #define EATING 2 typedef int semaphore; int state[N]; /* state of each philosopher */ semaphore mutex = 1; /* protects critical regions */ semaphore s[N]; /* one semaphore per philosopher, all 0 */ void philosopher(int i) { while (TRUE) { think(); take_forks(i); /* get both forks or block */ eat(); put_forks(i); /* release forks */ } } void take_forks(int i) { down(&mutex); state[i] = HUNGRY; test(i); /* try to acquire both forks */ up(&mutex); down(&s[i]); /* block if forks were not acquired */ } void put_forks(int i) { down(&mutex); state[i] = THINKING; test(LEFT); /* can left neighbour eat now? */ test(RIGHT); /* can right neighbour eat now? */ up(&mutex); } void test(int i) { if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) { state[i] = EATING; up(&s[i]); } } ``` **Explanation** 1. `take_forks(i)`: inside the mutex, the philosopher sets HUNGRY and calls `test(i)`. If left and right neighbours are not eating, he sets EATING and does `up(s[i])`. Then he leaves the mutex and does `down(s[i])`; this passes immediately if he got the forks, otherwise he blocks. 2. `put_forks(i)`: sets THINKING and tests the left and right neighbours. A hungry neighbour who can now eat is woken by `up(s[neighbour])`. 3. Two non-adjacent philosophers can eat together, so concurrency is maximum, and the forks are never held while waiting, so **deadlock cannot occur**. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. What is the defining rule of a monitor? A. It uses only binary semaphores B. Only one process may be active in the monitor at any instant C. It must run in kernel mode D. It allows unlimited concurrent procedures Answer: B. A monitor is a package of procedures and data with the rule of one active process at a time, enforced by the compiler. (Key point: Monitor definition) 2. What do wait(c) and signal(c) do? A. wait wakes a process, signal blocks one B. Both increment a counter C. wait blocks and releases the monitor; signal wakes one waiting process D. Both disable interrupts Answer: C. wait(c) blocks the caller and releases the monitor, signal(c) wakes a process waiting on c. (Key point: Condition variable operations) 3. Why does take_forks do down(&s[i]) after leaving the mutex? A. To block if test(i) did not give him the forks; it passes at once if it did B. To release the forks C. To wake the neighbours D. To protect the state array Answer: A. If test(i) did up(s[i]), down passes immediately; otherwise s[i] is 0 and he blocks. (Key point: take_forks mechanism) 4. Why can deadlock not occur in this solution while concurrency stays high? A. Only one philosopher may eat at a time B. Forks are acquired one by one C. Philosophers wait a random time D. Forks are taken only when both are free, and non-adjacent philosophers can eat together Answer: D. A philosopher takes both forks together or none, so no one holds a fork while waiting; two non-neighbours can eat at once. (Key point: Deadlock freedom and concurrency) ## Related in Operating System - [Dining philosophers problem and solution](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Adining-philosophers) — Operating System, chapter 3, asked 2× - [Readers-writers problem with semaphore](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Areaders-writers) — Operating System, chapter 3