A. Frank - P. Weisberg Operating Systems Classical Problems of Concurrency

A. Frank - P. Weisberg

Operating Systems

Classical Problems of Concurrency

2 A. Frank - P. Weisberg

Introduction to Concurrency

• Classical Problems of Concurrency

• Critical Regions

• Monitors

• Inter-Process Communication (IPC)

• Communications in Client-Server Systems


Classical Problems of Concurrency

• There are many of them – let’s briefly see three famous problems:

1. P/C Bounded-Buffer

2. Readers and Writers

3. Dining-Philosophers


Reminder: P/C problem with race condition


P/C Bounded-Buffer Problem

• We need 3 semaphores:1. A semaphore mutex (initialized to 1) to

have mutual exclusion on buffer access.2. A semaphore full (initialized to 0) to

synchronize producer and consumer on the number of consumable items.

3. A semaphore empty (initialized to n) to synchronize producer and consumer on the number of empty spaces.


Bounded-Buffer – Semaphores

• Shared data

semaphore full, empty, mutex;

Initially:

full = 0, empty = n, mutex = 1


Bounded-Buffer – Producer Process

do { …

produce an item in nextp …

wait(empty);wait(mutex);

…add nextp to buffer

…signal(mutex);signal(full);

} while (TRUE);


Bounded-Buffer – Consumer Process

do { wait(full)wait(mutex);

…remove an item from buffer to nextc

…signal(mutex);signal(empty);

…consume the item in nextc

…} while (TRUE);


Notes on P/C Bounded-Buffer Solution

• Remarks (from consumer point of view):– Putting signal(empty) inside the CS of the

consumer (instead of outside) has no effect since the producer must always wait for both semaphores before proceeding.

– The consumer must perform wait(full) before wait(mutex), otherwise deadlock occurs if consumer enters CS while the buffer is empty.

• Conclusion: using semaphores is a difficult art ...


Full P/C Bounded-Buffer Solution


Readers-Writers Problem

• A data set/repository 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.


Readers-Writers Dynamics

• Any number of reader activities and writer activities are running.

• At any time, a reader activity may wish to read data.

• At any time, a writer activity may want to modify the data.

• Any number of readers may access the data simultaneously.

• During the time a writer is writing, no other reader or writer may access the shared data.


Readers-Writers with active readers


Readers-Writers with an active writer


Should readers wait for waiting writer?


Readers-Writers problem

• There are various versions with different readers and writers preferences:

1. The first readers-writers problem, requires that no reader will be kept waiting unless a writer has obtained access to the shared data.

2. The second readers-writers problem, requires that once a writer is ready, no new readers may start reading.

3. In a solution to the first case writers may starve; In a solution to the second case readers may starve.


First Readers-Writers Solution (1)

• readcount (initialized to 0) counter keeps track of how many processes are currently reading.

• mutex semaphore (initialized to 1) provides mutual exclusion for updating readcount.

• wrt semaphore (initialized to 1) provides mutual exclusion for the writers; it is also used by the first or last reader that enters or exits the CS.


First Readers-Writers Solution (2)

• Shared data

semaphore mutex, wrt; int readcount;

Initially

mutex = 1, wrt = 1, readcount = 0


First Readers-Writers – Writer Process

do {

wait(wrt);

…

writing is performed

…

signal(wrt);

} while(TRUE);


First Readers-Writers – Reader Process

do { wait(mutex);

readcount++;if (readcount == 1)

wait(wrt);signal(mutex);

…reading is performed

…wait(mutex);readcount--;if (readcount == 0)

signal(wrt);signal(mutex);

} while(TRUE);


Dining Philosophers Problem (1)

• Philosophers spend their lives alternating between thinking and eating.

• Five philosophers can be seated around a circular table.

• There is a shared bowl of rice.• In front of each one is a plate.• Between each pair of philosophers

there is a chopstick, so there are five chopsticks.

• It takes two chopsticks to take/eat rice, so while n is eating neither n+1 nor n-1 can be eating.



• Each one thinks for a while, gets the chopsticks/forks needed, eats, and puts the chopsticks/forks down again, in an endless cycle.

• Illustrates the difficulty of allocating resources among process without deadlock and starvation.



• The challenge is to grant requests for chopsticks while avoiding deadlock and starvation.

• Deadlock can occur if everyone tries to get their chopsticks at once. Each gets a left chopstick, and is stuck, because each right chopstick is someone else’s left chopstick.


Dining Philosophers Solution (1)

• Each philosopher is a process.

• One semaphore per fork:– fork: array[0..4]

of semaphores– Initialization:

fork[i].count := 1 for i := 0..4

Process Pi:repeat think; wait(fork[i]); wait(fork[i+1 mod 5]); eat; signal(fork[i+1 mod 5]); signal(fork[i]); forever

Note: deadlock if each philosopher starts by picking up his left fork!



Possible solutions to avoid deadlock:• Allow at most four 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.



• A solution: admit only 4 philosophers at a time that try to eat.

• Then 1 philosopher can always eat when the other 3 are holding 1 fork.

• Hence, we can use another semaphore T that would limit at 4 the number of philosophers “sitting at the table”.

• Initialize: T.count := 4

Process Pi:repeat think; wait(T); wait(fork[i]); wait(fork[i+1 mod 5]); eat; signal(fork[i+1 mod 5]); signal(fork[i]); signal(T); forever



. . .



Documents

A. Frank - P. Weisberg Operating Systems Classical Problems of Concurrency