Classical Problems of
Synchronization
Classical Problems of Synchronization
• Classical problems used to test newly-
proposed synchronization schemes
– Bounded-Buffer Problem
– Readers and Writers Problem
– Dining-Philosophers Problem
Classical Problems of Synchronization
• n buffers, each can hold one item
• Semaphore mutex initialized to the value 1
• Semaphore full initialized to the value 0
• Semaphore empty initialized to the value n
Contd..
• The structure of the producer process
do {
...
/* produce an item in next_produced */
...
wait(empty);
wait(mutex);
...
/* add next produced to the buffer */
...
signal(mutex);
signal(full);
} while (true);
Contd..
The structure of the consumer process
Do {
wait(full);
wait(mutex);
...
/* remove an item from buffer to next_consumed */
...
signal(mutex);
signal(empty);
...
/* consume the item in next consumed */
...
} while (true);
Readers-Writers Problem
• A data set is shared among a number of concurrent processes
– Readers – only read the data set; they do not perform any updates
– Writers – can both read and write
• Problem – allow multiple readers to read at the same time
– Only one single writer can access the shared data at the same time
• Several variations of how readers and writers are considered –
all involve some form of priorities
• Shared Data
– Data set
– Semaphore rw_mutex initialized to 1
– Semaphore mutex initialized to 1
– Integer read_count initialized to 0
Readers-Writers Problem Variations
• First variation – no reader kept waiting unless
writer has permission to use shared object
• Second variation – once writer is ready, it
performs the write ASAP
• Both may have starvation leading to even
more variations
• Problem is solved on some systems by kernel
providing reader-writer locks
Dining-Philosophers Problem
Philosophers spend their lives alternating thinking and eating
Don’t interact with their neighbors, occasionally try to pick up 2 chopsticks (one at
a time) to eat from bowl
Need both to eat, then release both when done
In the case of 5 philosophers
Shared data
Bowl of rice (data set)
Semaphore chopstick [5] initialized to 1
Dining-Philosophers Problem Algorithm
(Cont.)
• Deadlock handling
– Allow at most 4 philosophers to be sitting
simultaneously at the table.
– Allow a philosopher to pick up the forks only if both
are available (picking must be done in a critical section.
– Use an asymmetric solution -- an odd-numbered
philosopher picks up first the left chopstick and then
the right chopstick. Even-numbered philosopher picks
up first the right chopstick and then the left chopstick.
Monitors
• A high-level abstraction that provides a convenient and effective mechanism for process
synchronization
• Abstract data type, internal variables only accessible by code within the procedure
• Only one process may be active within the monitor at a time
• But not powerful enough to model some synchronization schemes
monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
procedure Pn (…) {……}
Initialization code (…) { … }
}
}
Schematic view of a Monitor
Condition Variables Choices
• If process P invokes x.signal(), and process Q is suspended in
x.wait(), what should happen next?
– Both Q and P cannot execute in paralel. If Q is resumed, then P must
wait
• Options include
– Signal and wait – P waits until Q either leaves the monitor or it waits
for another condition
– Signal and continue – Q waits until P either leaves the monitor or it
waits for another condition
– Both have pros and cons – language implementer can decide
– Monitors implemented in Concurrent Pascal compromise
• P executing signal immediately leaves the monitor, Q is resumed
– Implemented in other languages including Mesa, C#, Java
Monitor Solution to Dining Philosophers
monitor DiningPhilosophers
{
enum { THINKING; HUNGRY, EATING) state [5] ;
condition self [5];
void pickup (int i) {
state[i] = HUNGRY;
test(i);
if (state[i] != EATING) self[i].wait;
}
void putdown (int i) {
state[i] = THINKING;
// test left and right neighbors
test((i + 4) % 5);
test((i + 1) % 5);
}
Solution to Dining Philosophers (Cont.)
void test (int i) {
if ((state[(i + 4) % 5] != EATING) &&
(state[i] == HUNGRY) &&
(state[(i + 1) % 5] != EATING) ) {
state[i] = EATING ;
self[i].signal () ;
}
}
initialization_code() {
for (int i = 0; i < 5; i++)
state[i] = THINKING;
}
}
Contd..
• Each philosopher i invokes the operations pickup() and
putdown() in the following sequence:
DiningPhilosophers.pickup(i);
EAT
DiningPhilosophers.putdown(i);
• No deadlock, but starvation is possible
