Introduction to

Operating Systems
C-CS316 Spring 2024

LECTURE 07:
Process Synchronization (Part 2)
Dr. Basma Hassan Dr. Ahmed Salama
[email protected] [email protected]

Faculty of Computing and Information Sciences

1
Chapters 6 &7: Process Synchronization
Producer-Consumer Problem
The Critical-Section Problem
Peterson’s Solution
Hardware Support for Synchronization
Mutex Locks
Semaphores
Monitors
Liveness
Classic Problems of Synchronization

Faculty of Computing and Information Sciences

2
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
• Pseudocode syntax of a monitor:
monitor monitor_name {
// shared variable declarations

procedure P1 (…) {……}

procedure P2 (…) {……}

procedure Pn (…) {……}

initialization code (…) {……} Schematic view of a

} Monitor

Faculty of Computing and Information Sciences

3
Monitor Implementation Using Semaphores

• Variables
semaphore mutex
mutex = 1

• Each procedure P is replaced by

wait(mutex);
…
body of P;
…
signal(mutex);

• Mutual exclusion within a monitor is ensured

Faculty of Computing and Information Sciences

4
Condition Variables
• Condition variables are used to
manage synchronization based on
specific conditions.

• condition x, y;

• Two operations are allowed on a

condition variable:
• x.wait() – a process that invokes the
operation is suspended until
x.signal()
• x.signal() – resumes one of
processes (if any) that invoked
x.wait()
• If no x.wait() on the variable, then it
has no effect on the variable Monitor with
Condition Variables

Faculty of Computing and Information Sciences

5
Monitor Implementation – Condition Variables
• Mutual exclusion within a monitor is ensured

• Variables
semaphore mutex; // (initially = 1)
semaphore next; // (initially = 0)
int next_count = 0; // number of processes waiting inside the monitor

• Each function P will be replaced by semaphore x_sem; // (initially = 0)

int x_count = 0;
wait(mutex);
… x.wait() x.signal()
body of P;
… For each condition x_count++; if (x_count > 0)
if (next_count > 0) variable x, if (next_count > 0) {
we have: signal(next); next_count++;
signal(next)
else else signal(x_sem);
signal(mutex); signal(mutex); wait(next);
wait(x_sem); next_count--;
x_count--; }

Faculty of Computing and Information Sciences

6
Resuming Processes within a Monitor

• If several processes queued on condition variable x, and x.signal()

is executed, which process should be resumed?

• FCFS frequently not adequate

• Use the conditional-wait construct of the form
x.wait(c)
• where:
• c is an integer (called the priority number)
• The process with lowest number (highest priority) is scheduled next

Faculty of Computing and Information Sciences

7
Single Resource Allocation
• Allocate a single resource among competing processes
using priority numbers monitor ResourceAllocator {
• specifies the maximum time a process plans to use the boolean busy;
resource condition x;

• The process with the shortest time is allocated the void acquire(int time) {
resource first if (busy)
x.wait(time);
• Let R is an instance of type ResourceAllocator busy = true;
(monitor) }
• Access to ResourceAllocator is done via: void release() {
busy = false;
R.acquire(t); x.signal();
... }
access the resource;
... initialization code() {
R.release; busy = false;
}
• Where t is the maximum time a process plans to use the }
resource

Faculty of Computing and Information Sciences

8
Classical Problems of Synchronization

• Classical problems used to test newly-proposed synchronization

schemes

Bounded-Buffer Problem

Readers and Writers Problem

Dining-Philosophers Problem

Faculty of Computing and Information Sciences

9
Bounded Buffer Problem
The structure of a producer process The structure of a consumer process
while (true) { while (true) {
... wait(full);
/* produce an item in next_produced */ wait(mutex);
... ...
wait(empty); /* remove an item from buffer to next_consumed */
wait(mutex); ...
... signal(mutex);
/* add next produced to the buffer */ signal(empty);
... ...
signal(mutex); /* consume the item in next consumed */
signal(full); ...
} }

• n buffers, each can hold one item

• Semaphore mutex initialized to the value 1
• Semaphore full initialized to the value 0 (count the number of full buffers)
• Semaphore empty initialized to the value n (count the number of empty buffers)

Faculty of Computing and Information Sciences

10
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)
• first readers–writers problem
• second readers–writers problem

Faculty of Computing and Information Sciences

11
Readers-Writers Problem (Cont.)

The structure of a writer process The structure of a reader process

while (true) { while (true){
wait(rw_mutex); wait(mutex);
... read_count++;
/* writing is performed */ if (read_count == 1) /* first reader */
... wait(rw_mutex);
signal(rw_mutex); signal(mutex);
} ...
/* reading is performed */
...
wait(mutex);
Shared Data read_count--;
if (read_count == 0) /* last reader */
• Data set signal(rw_mutex);
• Semaphore rw_mutex initialized to 1 signal(mutex);
• Semaphore mutex initialized to 1 }
• Integer read_count initialized to 0

Faculty of Computing and Information Sciences

12
Readers-Writers Problem Variations

• The solution can result in a situation where a writer process

never writes.
• “First reader-writer” problem.

• The “Second reader-writer” problem is a variation of the

first reader-writer problem that state:
• Once a writer is ready to write, no “newly arrived reader” is allowed
to read.

• Both the first and second may result in starvation leading to

even more variations

Faculty of Computing and Information Sciences

13
Dining-Philosophers Problem

• N philosophers sit at a round table with a

bowel of rice in the middle. They spend their
lives alternating thinking and eating. They do
not 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, the shared data

• Bowl of rice (data set)
• Semaphore chopstick [5] initialized to 1

Faculty of Computing and Information Sciences

14
Dining-Philosophers Problem Algorithm

• Semaphore Solution
• The structure of Philosopher i :
while (true){
wait (chopstick[i]);
wait (chopstick[(i + 1) % 5]);

/* eat for awhile */

signal (chopstick[i]);
signal (chopstick[(i + 1) % 5]);

/* think for awhile */

Faculty of Computing and Information Sciences

15
Monitor Solution to Dining Philosophers
• Imposes the restriction that a philosopher may pick up his/her
chopsticks only if both of them are available.
monitor DiningPhilosophers { // checks if philosopher i can start eating.
enum {THINKING; HUNGRY, EATING} state [5]; void test (int i) {
condition self [5]; if ((state[(i + 4) % 5] != EATING) &&
(state[i] == HUNGRY) &&
void pickup (int i) { (state[(i + 1) % 5] != EATING) ) {
state[i] = HUNGRY; state[i] = EATING ;
test(i); self[i].signal() ;
if (state[i] != EATING) self[i].wait(); }
}
}
void putdown (int i) {
state[i] = THINKING; initialization_code() {
// test left and right neighbors for (int i = 0; i < 5; i++)
test((i + 4) % 5); state[i] = THINKING;
test((i + 1) % 5); }
} }

Faculty of Computing and Information Sciences

17
Solution to Dining Philosophers (Cont.)

• 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

Faculty of Computing and Information Sciences

18
Liveness

• Processes may have to wait indefinitely while trying to

acquire a synchronization tool such as a mutex lock or
semaphore.

• Waiting indefinitely violates the progress and bounded-

waiting criteria

• Liveness refers to a set of properties that a system must

satisfy to ensure processes make progress.
• Indefinite waiting is an example of a liveness failure.

Faculty of Computing and Information Sciences

19
Liveness (Cont.)
• Deadlock – two or more processes are waiting indefinitely for an event that can be
caused by only one of the waiting processes
• Let S and Q be two semaphores initialized to 1

P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
... ...
signal(S); signal(Q);
signal(Q); signal(S);

• Consider if P0 executes wait(S) and P1 wait(Q).

• When P0 executes wait(Q), it must wait until P1 executes signal(Q)
• However, P1 is waiting until P0 execute signal(S).
• Since these signal() operations will never be executed, P0 and P1 are deadlocked.

Faculty of Computing and Information Sciences

20
 End of Lecture!
Thanks for your Attention!

Faculty of Computing and Information Sciences

21