MIT School of Computing

Department of Computer Science & Engineering

Third Year Engineering

21BTCS504-Operating System

Class - T.Y.
PLD(SEM-I)

Unit - III

● PROCESS SYNCHRONIZATION AND DEADLOCKS

AY 2024-2025 SEM-I

1
 MIT School of Computing
Department of Computer Science & Engineering

Unit-III Syllabus

Background, The Critical-Section Problem, Peterson's

Solution, Synchronization Hardware, Semaphores, Classic
Problems of Synchronization,
PLD Monitors, Synchronization
Example, Atomic Transactions, Deadlocks, System Model,
Deadlock Characterization, Methods for Handling
Deadlocks, Deadlock Prevention, Deadlock Avoidance,
Deadlock Detection, Recovery from Deadlock

2
 MIT School of Computing
Department of Computer Science & Engineering

Background
Concurrent access to shared data may result in data
inconsistency
Maintaining data consistency requires mechanisms to
ensure the orderly execution of cooperating processes
Suppose that we wanted PLD to provide a solution to the
consumer-producer problem that fills all the buffers. We can
do so by having an integer count that keeps track of the
number of full buffers. Initially, count is set to 0. It is
incremented by the producer after it produces a new buffer
and is decremented by the consumer after it consumes a
buffer.

3
 MIT School of Computing
Department of Computer Science & Engineering

Background
Concurrent access to shared data may result in data
inconsistency
Maintaining data consistency requires mechanisms to
ensure the orderly execution of cooperating processes
Suppose that we wanted PLD to provide a solution to the
consumer-producer problem that fills all the buffers. We can
do so by having an integer count that keeps track of the
number of full buffers. Initially, count is set to 0. It is
incremented by the producer after it produces a new buffer
and is decremented by the consumer after it consumes a
buffer.

4
Producer
while (true) {
/* produce an item and put in nextProduced
*/
while (count == BUFFER_SIZE)
; // do nothing
buffer [in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
count++;
}
Consumer
while (true) {
while (count == 0)
; // do nothing
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
count--;
/* consume the item in
nextConsumed
}
Race Condition
• count++ could be implemented as
register1 = count
register1 = register1 + 1
count = register1
• count-- could be implemented as
register2 = count
register2 = register2 - 1
count = register2
• Consider this execution interleaving with “count = 5” initially:
S0: producer execute register1 = count {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = count {register2 = 5}
S3: consumer execute register2 = register2 - 1 {register2 = 4}
S4: producer execute count = register1 {count = 6 }
S5: consumer execute count = register2 {count = 4}
Solution to Critical-Section Problem
Requirements:
1. Mutual Exclusion - If process Pi is executing in its critical section,
then no other processes can be executing in their critical sections.
2. Progress - If no process is executing in its critical section and there
exist some processes that wish to enter their critical section, then
the selection of the processes that will enter the critical section
next cannot be postponed indefinitely.
3. Bounded Waiting - A bound must exist on the number of times that
other processes are allowed to enter their critical sections after a
process has made a request to enter its critical section and before
that request is granted.
⚫ Assume that each process executes at a nonzero speed
⚫ No assumption concerning relative speed of the N processes
Peterson’s Solution
• Two process solution
• Assume that the LOAD and STORE instructions
are atomic; that is, cannot be interrupted.
• The two processes share two variables:
• int turn;
• Boolean flag[2]
• The variable turn indicates whose turn it is to
enter the critical section.
• The flag array is used to indicate if a process is
ready to enter the critical section. flag[i] = true
implies that process Pi is ready!
Algorithm for Process Pi

do {
flag[i] = TRUE;
turn = j;
while (flag[j] && turn == j);
critical section
flag[i] = FALSE;
remainder section
} while (TRUE);
 Synchronization Hardware
• Many systems provide hardware support for critical section
code
• Uniprocessors – could disable interrupts
• Currently running code would execute without
preemption
• Generally too inefficient on multiprocessor systems
• Operating systems using this not broadly scalable
• Modern machines provide special atomic hardware
instructions
• Atomic = non-interruptible
• Either test memory word and set value
• Or swap contents of two memory words
Semaphore
• Synchronization tool that does not require busy waiting
• Semaphore S – integer variable
• Two standard operations modify S: wait() and signal()
• Originally called P() and V()
• Less complicated
• Can only be accessed via two indivisible (atomic)
operations
• wait (S) {
while S <= 0
; // no-op
S--;
}
• signal (S) {
S++;
}
Semaphore as General Synchronization Tool
• Counting semaphore – integer value can range over an unrestricted
domain
• Binary semaphore – integer value can range only between 0
and 1; can be simpler to implement
• Also known as mutex locks
• Can implement a counting semaphore S as a binary semaphore
• Provides mutual exclusion
Semaphore mutex; // initialized to 1
do {
wait (mutex);
// Critical Section
signal (mutex);
// remainder section
} while (TRUE);
Semaphore Implementation
• Must guarantee that no two processes can execute wait ()
and signal () on the same semaphore at the same time
• Thus, implementation becomes the critical section
problem where the wait and signal code are placed in the
critical section.
• Could now have busy waiting in critical section
implementation
• But implementation code is short
• Little busy waiting if critical section rarely occupied
• Note that applications may spend lots of time in critical
sections and therefore this is not a good solution.
Semaphore Implementation with no Busy waiting
• With each semaphore there is an associated
waiting queue. Each entry in a waiting queue has
two data items:
• value (of type integer)
• pointer to next record in the list
• Two operations:
• block – place the process invoking the
operation on the appropriate waiting
queue.
• wakeup – remove one of processes in the
waiting queue and place it in the ready queue.
Semaphore Implementation with
no Busy waiting (Cont.)

• Implementation of wait:
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}
• Implementation of signal:

signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}
Deadlock and Starvation
• 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);
• Starvation – indefinite blocking. A process may never be removed from the
semaphore queue in which it is suspended
• Priority Inversion – Scheduling problem when lower-priority process holds a
lock needed by higher-priority process
 Classical Problems of Synchronization

• Bounded-Buffer Problem

• Readers and Writers Problem

• Dining-Philosophers Problem
 Bounded-Buffer Problem
• 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.
 Bounded Buffer Problem (Cont.)
• The structure of the producer process
do {
// produce an item in nextp
wait (empty);
wait (mutex);
// add the item to the buffer
signal (mutex);
signal (full);
} while (TRUE);
 Bounded Buffer Problem (Cont.)
• The structure of the 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);
 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.
• Shared Data
• Data set
• Semaphore mutex initialized to 1 (controls access to readcount)
• Semaphore wrt initialized to 1 (writer access)
• Integer readcount initialized to 0 (how many processes are
reading object)
Readers-Writers Problem (Cont.)

• The structure of a writer process

do {
wait (wrt) ;
// writing is performed
signal (wrt) ;
} while (TRUE);
 Readers-Writers Problem (Cont.)
• The structure of a 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

• Shared data
• Bowl of rice (data set)
• Semaphore chopstick [5] initialized to 1
Dining-Philosophers Problem (Cont.)
• The structure of Philosopher i:
do {
wait ( chopstick[i] );
wait ( chopStick[ (i + 1) % 5] );
// eat
signal ( chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
// think
} while (TRUE);

What is the problem with the above?

More Problems with Semaphores

• Relies too much on programmers not

making mistakes (accidental or deliberate)
• Incorrect use of semaphore operations:
• signal (mutex) …. wait (mutex)
• wait (mutex) … wait (mutex)
• Omitting of wait (mutex) or signal
(mutex) (or both)
Monitors
• A high-level abstraction that provides a convenient and effective
mechanism for process synchronization

• Only one process may be active within the monitor at a time

monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
…
procedure Pn (…) {……}
Initialization code ( ….) { … }
…
}
}
Schematic view of a Monitor
Condition Variables

• condition x, y;
• Two operations on a condition variable:
• x.wait () – a process that invokes the operation is
suspended.
• x.signal () – resumes one of processes (if any) that
invoked x.wait ()
Monitor with Condition Variables
Solution to Dining Philosophers
monitor DP
{
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;
}
}
 Solution to Dining Philosophers (Cont.)

• Each philosopher I invokes the operations pickup()

and putdown() in the following sequence:

DiningPhilosophters.pickup (i);

EAT

DiningPhilosophers.putdown (i);
Monitor Implementation Using Semaphores

• Variables
semaphore mutex; // (initially = 1)
semaphore next; // (initially = 0)
int next-count = 0;

• Each procedure F will be replaced by

wait(mutex);
…
body of F;

…
if (next_count > 0)
signal(next)
else
signal(mutex);

• Mutual exclusion within a monitor is ensured.

 Monitor Implementation

• For each condition variable x, we have:

semaphore x_sem; // (initially = 0)

int x-count = 0;

• The operation x.wait can be implemented as:

x-count++;
if (next_count > 0)
signal(next);
else
signal(mutex);
wait(x_sem);
x-count--;
 Monitor Implementation

• The operation x.signal can be implemented as:

if (x-count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}
A Monitor to Allocate Single Resource

monitor ResourceAllocator
{
boolean busy;
condition x;
void acquire(int time) {
if (busy)
x.wait(time);
busy = TRUE;
}
void release() {
busy = FALSE;
x.signal();
}
initialization code() {
busy = FALSE;
}
}
 Synchronization Examples

• Solaris

• Windows XP

• Linux

• Pthreads
 Deadlock
Deadlock is a situation where a set of processes are
blocked because each process is holding a resource and
waiting for another resource acquired by some other
process.
Consider an example when two trains are coming toward
each other on the same track and there is only one track,
none of the trains can move once they are in front of each
other. A similar situation occurs in operating systems when
there are two or more processes that hold some resources
and wait for resources held by other(s). For example, in the
below diagram, Process 1 is holding Resource 1 and waiting
for resource 2 which is acquired by process 2, and process 2
is waiting for resource 1.
The Deadlock Problem
• A set of blocked processes each holding a resource
and waiting to acquire a resource held by another
process in the set
• Example
• System has 2 disk drives
• P and P each hold one disk drive and each needs
1 2
another one
• Example
• semaphores A and B, initialized to 1
P0 P1
wait (A); wait(B)
wait (B); wait(A)
Bridge Crossing Example

• Traffic only in one direction

• Each section of a bridge can be viewed as a resource
• If a deadlock occurs, it can be resolved if one car backs up
(preempt resources and rollback)
• Several cars may have to be backed up if a deadlock occurs
• Starvation is possible
• Note – Most OSes do not prevent or deal with deadlocks
System Model
• Resource types R1, R2, . . ., Rm
CPU cycles, memory space, I/O devices
• Each resource type Ri has Wi instances.
• Each process utilizes a resource as follows:
• request
• use
• release
Deadlock Characterization
Deadlock can arise if four conditions hold
simultaneously.
• Mutual exclusion: only one process at a time can use a
resource
• Hold and wait: a process holding at least one resource is
waiting to acquire additional resources held by other
processes
• No preemption: a resource can be released only
voluntarily by the process holding it, after that process has
completed its task
• Circular wait: there exists a set {P1, P2, …, Pn} of waiting
processes such that P1 is waiting for a resource that is held
by P2, P2 is waiting for a resource that is held by P3, …, Pn–
1 is waiting for a resource that is held by Pn, and Pn is
waiting for a resource that is held by P1.
Resource-Allocation
A set of vertices V and a set of
Graph
edges E.
• V is partitioned into two types:
• P = {P1, P2, …, Pn}, the set consisting of all the processes in the
system

• R = {R1, R2, …, Rm}, the set consisting of all resource types in the
system
• request edge – directed edge P1 → Rj
• assignment edge – directed edge Rj → Pi
Resource-Allocation Graph
(Cont.)
• Process

• Resource Type with 4 instances

Pi
• Pi requests instance of Rj
Rj

• Pi is holding an instance ofPiRj

Rj
Example of a Resource Allocation Graph
Resource Allocation Graph With A Deadlock
Graph With A Cycle But No Deadlock
Basic Facts
• If graph contains no cycles ⇒ no
deadlock

• If graph contains a cycle ⇒

• if only one instance per resource type,
then deadlock
• if several instances per resource type,
possibility of deadlock
Methods for Handling Deadlocks
• Ensure that the system will never enter a deadlock
state

• Allow the system to enter a deadlock state and then

recover

• Ignore the problem and pretend that deadlocks

never occur in the system; used by most operating
systems, including UNIX
Deadlock Prevention
Restrain the ways request can be made

• Mutual Exclusion – not required for sharable

resources; must hold for nonsharable resources

• Hold and Wait – must guarantee that whenever

a process requests a resource, it does not hold
any other resources
• Require process to request and be allocated all its
resources before it begins execution, or allow process
to request resources only when the process has none
• Low resource utilization; starvation possible
Deadlock Prevention (Cont.)
• No Preemption –
• If a process that is holding some resources requests
another resource that cannot be immediately allocated
to it, then all resources currently being held are released
• Preempted resources are added to the list of resources
for which the process is waiting
• Process will be restarted only when it can regain its old
resources, as well as the new ones that it is requesting

• Circular Wait – impose a total ordering of all

resource types, and require that each process
requests resources in an increasing order of
enumeration
Deadlock Avoidance
Requires that the system has some additional a priori information
available

• Simplest and most useful model requires that

each process declare the maximum number of
resources of each type that it may need

• The deadlock-avoidance algorithm dynamically

examines the resource-allocation state to ensure
that there can never be a circular-wait condition

• Resource-allocation state is defined by the

number of available and allocated resources, and
the maximum demands of the processes
Safe State
• When a process requests an available resource, system must
decide if immediate allocation leaves the system in a safe state

• System is in safe state if there exists a sequence <P1, P2, …, Pn>

of ALL the processes is the systems such that for each Pi, the
resources that Pi can still request can be satisfied by currently
available resources + resources held by all the Pj, with j < i
• That is:
• If Pi resource needs are not immediately available, then Pi can wait
until all Pj have finished
• When Pj is finished, Pi can obtain needed resources, execute, return
allocated resources, and terminate
• When Pi terminates, Pi +1 can obtain its needed resources, and so on
Basic Facts
• If a system is in safe state ⇒ no
deadlocks

• If a system is in unsafe state ⇒

possibility of deadlock

• Avoidance ⇒ ensure that a system will

never enter an unsafe state.
Safe, Unsafe , Deadlock State
Avoidance algorithms
• Single instance of a resource type
• Use a resource-allocation graph

• Multiple instances of a resource type

• Use the banker’s algorithm
Resource-Allocation Graph Scheme

• Claim edge Pi → Rj indicated that process Pj may

request resource Rj; represented by a dashed line

• Claim edge converts to request edge when a process

requests a resource

• Request edge converted to an assignment edge when

the resource is allocated to the process

• When a resource is released by a process, assignment

edge reconverts to a claim edge

• Resources must be claimed a priori in the system

Resource-Allocation Graph
Unsafe State In Resource-Allocation Graph
Resource-Allocation Graph Algorithm

• Suppose that process Pi requests a

resource Rj

• The request can be granted only if

converting the request edge to an
assignment edge does not result in the
formation of a cycle in the resource
allocation graph
Banker’s Algorithm
• Multiple instances

• Each process must declare its maximum

resource use (a priori)

• When a process requests a resource it may

have to wait

• When a process gets all its resources it must

return them in a finite amount of time
 Data Structures for the Banker’s Algorithm

Let n = number of processes, and m = number of resources types.

• Available: Vector of length m. If available [j] = k, there

are k instances of resource type Rj available
• Max: n x m matrix. If Max [i,j] = k, then process Pi may
request at most k instances of resource type Rj
• Allocation: n x m matrix. If Allocation[i,j] = k then Pi is
currently allocated k instances of Rj
• Need: n x m matrix. If Need[i,j] = k, then Pi may need k
more instances of Rj to complete its task
Need [i,j] = Max[i,j] – Allocation [i,j]
Safety Algorithm
1. Let Work and Finish be vectors of length m and n,
respectively. Initialize:
Work = Available
Finish [i] = false for i = 0, 1, …, n- 1

2. Find and i such that both:

(a) Finish [i] = false
(b) Needi ≤ Work
If no such i exists, go to step 4
3. Work = Work + Allocationi
Finish[i] = true
go to step 2
4. If Finish [i] == true for all i, then the system is in a safe state
Resource-Request Algorithm for Process Pi

Request = request vector for process Pi. If Requesti [j]

= k then process Pi wants k instances of resource type
Rj
1. If Requesti ≤ Needi go to step 2. Otherwise, raise error
condition, since process has exceeded its maximum claim
2. If Requesti ≤ Available, go to step 3. Otherwise Pi must
wait, since resources are not available
3. Pretend to allocate requested resources to Pi by modifying
the state as follows:
Available = Available – Request;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;
● If safe ⇒ the resources are allocated to Pi
● If unsafe ⇒ Pi must wait, and the old resource-allocation state is
restored
Example of Banker’s Algorithm
• 5 processes P0 through P4;
3 resource types:
A (10 instances), B (5instances), and C (7 instances)
Snapshot at time T0:
Allocation Max Available
ABC ABC ABC
P0 010 753 332
P1 200 322
P2 302 902
P3 211 222
P4 002 433
Example (Cont.)
• The content of the matrix Need is defined to be Max – Allocation

Need
ABC
P0 743
P1 122
P2 600
P3 011
P4 431

• The system is in a safe state since the sequence < P1, P3, P4, P2, P0>
satisfies safety criteria
Example: P1 Requests (1,0,2)
• Check that Request ≤ Available (that is, (1,0,2) ≤ (3,3,2) ⇒ true
Allocation Need Available
ABC ABC ABC
P0 010 743 230
P1 302 020
P2 302 600
P3 211 011
P4 002 431
• Executing safety algorithm shows that sequence < P1, P3, P4, P0,
P2> satisfies safety requirement
• Can request for (3,3,0) by P4 be granted?
• Can request for (0,2,0) by P0 be granted?
Deadlock Detection
• Allow system to enter deadlock state

• Detection algorithm

• Recovery scheme
 Single Instance of Each Resource Type

• Maintain wait-for graph

• Nodes are processes
• P → P if P is waiting for P
i j i j

• Periodically invoke an algorithm that

searches for a cycle in the graph. If there is
a cycle, there exists a deadlock

• An algorithm to detect a cycle in a graph

requires an order of n2 operations, where
n is the number of vertices in the graph
Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph Corresponding wait-for graph

 Several Instances of a Resource Type

• Available: A vector of length m indicates the number

of available resources of each type.

• Allocation: An n x m matrix defines the number of

resources of each type currently allocated to each
process.

• Request: An n x m matrix indicates the current request

of each process. If Request [ij] = k, then process Pi is
requesting k more instances of resource type Rj.
Detection Algorithm
1. Let Work and Finish be vectors of length m and n,
respectively Initialize:
(a) Work = Available
(b) For i = 1,2, …, n, if Allocationi ≠ 0, then
Finish[i] = false;otherwise, Finish[i] = true
2. Find an index i such that both:
(a) Finish[i] == false
(b) Requesti ≤ Work

If no such i exists, go to step 4

Detection Algorithm (Cont.)
3. Work = Work + Allocationi
Finish[i] = true
go to step 2

4. If Finish[i] == false, for some i, 1 ≤ i ≤ n, then the system is in deadlock

state. Moreover, if Finish[i] == false, then Pi is deadlocked

Algorithm requires an order of O(m x n2) operations to detect whether the

system is in deadlocked state
Example of Detection Algorithm
• Five processes P0 through P4; three resource types
A (7 instances), B (2 instances), and C (6 instances)
• Snapshot at time T0:
Allocation Request Available
ABC ABC ABC
P0 010 000 000
P1 200 202
P2 303 000
P3 211 100
P4 002 002
• Sequence <P0, P2, P3, P1, P4> will result in Finish[i] = true for all i
Example (Cont.)
• P2 requests an additional instance of type C
Request
ABC
P0 000
P1 201
P2 001
P3 100
P4 002
• State of system?
• Can reclaim resources held by process P0, but insufficient resources to fulfill
the pending requests from the other processes
• Deadlock exists, consisting of processes P1, P2, P3, and P4
Detection-Algorithm Usage
• When, and how often, to invoke depends on:
• How often a deadlock is likely to occur?
• How many processes will need to be rolled back?
• one for each disjoint cycle

• If detection algorithm is invoked arbitrarily, there

may be many cycles in the resource graph and so
we would not be able to tell which of the many
deadlocked processes “caused” the deadlock
Recovery from Deadlock: Process Termination

• Abort all deadlocked processes

• Abort one process at a time until the deadlock cycle is

eliminated

• In which order should we choose to abort?

• Priority of the process
• How long process has computed, and how much longer to
completion
• Resources the process has used
• Resources process needs to complete
• How many processes will need to be terminated
• Is process interactive or batch?
 Recovery from Deadlock: Resource Preemption

• Selecting a victim – minimize cost

• Rollback – return to some safe state, restart

process for that state

• Starvation – same process may always be

picked as victim, include number of rollback in
cost factor
Questions
Q.1 What is deadlock? Explain necessary conditions for deadlock.
Q.2 Explain deadlock prevention.
Q.3 Explain Bankers algorithm with suitable example.
Q.4 Explain the concept of resource allocation graph.
Q.5 Explain deadlock avoidance.
Q.6 Explain the concept of safe state with suitable example.
Q.7 What is critical section problems and what are the possible
solutions to the problems.
Q.8 Explain the readers and writers problem with the help of
semaphore.
Q.9 Explain software approaches to solve synchronization
problem.
Q.10 Explain hardware approaches to solve synchronization
problem.
82
 Questions
Q.11 Define process synchronization and explain petersons
solution algorithm.
Q.12 What is semaphore. Differentiate between mutex and
semaphore.
Q.13 Explain the producer and consumer problem with the help
of semaphore.
Q.14 Explain deadlock detection and recovery.
Q.15 What is monitor? Explain with any suitable example.

83