R.M.K.

ENGINEERING COLLEGE
(An Autonomous Institution)
R.S.M Nagar, Kavaraipettai, Gummidipoondi Taluk, Thiruvallur District, Tamil Nadu - 601206
Affiliated to Anna University, Chennai / Approved by AICTE, New Delhi / Accredited by NAAC with A+ Grade
An ISO 9001:2015 Certified Institution / All the Eligible UG Programs are Accredited by NBA, New Delhi

22CS304
OPERATING SYSTEM
Dr. Lakshmi Haritha M
Associate Professor
Department of CSE
R.M.K Engineering College
COURSE OUTCOMES
• CO1: Implement the basic concepts of operating systems and process.

• CO2: Analyse various CPU scheduling algorithms and thread mechanism.

• CO3: Implement the concepts of process synchronization and deadlocks.

• CO4: Design various memory management schemes to given situation.

• CO5: Implement various I/O and file management techniques.

 Unit-3

PROCESS SYNCHRONISATION AND DEADLOCKS

Process Synchronization: The critical-section problem – Peterson’s Solution,
Synchronization hardware, Mutex locks, Semaphores, monitors - Classic problems of
synchronization: Bounded Buffer Problem - Reader’s & Writer Problem, Dinning
Philosopher Problem. Deadlock: System model - Deadlock characterization, Methods
for handling deadlocks - Deadlock prevention - Deadlock avoidance - Deadlock
detection - Recovery from deadlock.
BACKGROUND
.
 Background
• Processes can execute concurrently
• May be interrupted at any time, partially completing execution

• Concurrent access to shared data may result in data inconsistency

• Maintaining data consistency requires mechanisms to ensure the orderly execution of

cooperating processes

• Illustration of the problem:

Suppose that we wanted to provide a solution to the consumer-producer problem that fills
all the buffers. We can do so by having an integer counter that keeps track of the
number of full buffers. Initially, counter 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.
Producer
while (true) {
/* produce an item in next produced */

while (counter == BUFFER_SIZE) ;

/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
Consumer
while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */
}
Race Condition
• counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1

• counter-- could be implemented as

register2 = counter
register2 = register2 - 1
counter = register2

• Consider this execution interleaving with “count = 5” initially:

S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 – 1 {register2 = 4}
S4: producer execute counter = register1 {counter = 6 }
S5: consumer execute counter = register2 {counter = 4}
CRITICAL SECTION PROBLEM
.
 Critical Section Problem
• Consider system of n processes {p0, p1, … pn-1}

• Each process has critical section segment of code

• Process may be changing common variables, updating table, writing file, etc
• When one process in critical section, no other may be in its critical section

• Critical section problem is to design protocol to solve this

• Each process must ask permission to enter critical section in entry section,
may follow critical section with exit section, then remainder section
 Critical Section

• General structure of process Pi

Algorithm for Process Pi
do {

while (turn == j);

critical section
turn = j;

remainder section
} while (true);
 Solution to Critical-Section Problem
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

 Critical-Section Handling in OS
Two approaches depending on if kernel is preemptive or non-
preemptive

• Preemptive – allows preemption of process when running in kernel

mode

• Non-preemptive – runs until exits kernel mode, blocks, or voluntarily

yields CPU

• Essentially free of race conditions in kernel mode

PETERSON’S SOLUTION.
 Peterson’s Solution
• Good algorithmic description of solving the problem

• Two process solution

• Assume that the load and store machine-language 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);
 Peterson’s Solution (Cont.)
• Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
Pi enters CS only if:

either flag[j] = false or

turn = i
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met
SYNCHRONIZATION HARDWARE
 Synchronization Hardware
• There are three hardware instructions that provide support for
solving the critical-section problem.
• Memory Barriers

• Hardware Instructions

• Atomic variables
Synchronization Hardware – Memory Barriers
• How a computer architecture determines what memory guarantees it will provide
to an application program is known as its memory model.

1. Strongly ordered - where a memory modification on one processor is immediately

visible to all other processors.

2. Weakly ordered, where modifications to memory on one processor may not be

immediately visible to other processors.

• Computer architectures provide instructions that can force any changes in

memory to be propagated to all other processors, thereby ensuring that memory
modifications are visible to threads running on other processors.

• Such instructions are known as memory barriers or memory fences.

Synchronization Hardware – Hardware Instructions
• Many modern computer systems provide special hardware
instructions that allow us either to test and modify the content of a
word or to swap the contents of two words atomically.

• This is accomplished by test and set() and compare and swap()

instructions.

• The important characteristic of test and set() instruction is that it is

executed atomically. Thus, if two test and set() instructions are
executed simultaneously each on a different core), they will be
executed sequentially in some arbitrary order.
Solution using test_and_set()
● Shared Boolean variable lock, initialized to FALSE
● Solution:
do {
while (test_and_set(&lock))
; /* do nothing */
/* critical section */
lock = false;
/* remainder section */

} while (true);
 compare_and_swap Instruction
Definition:
int compare _and_swap(int *value, int expected, int new_value) {
int temp = *value;

if (*value == expected)
*value = new_value;
return temp;
}

1. Executed atomically
2. Returns the original value of passed parameter “value”
3. Set the variable “value” the value of the passed parameter
“new_value” but only if “value” ==“expected”. That is, the swap
takes place only under this condition.
 Solution using compare_and_swap
• Shared integer “lock” initialized to 0;
• Solution:
do {
while (compare_and_swap(&lock, 0, 1) != 0)
; /* do nothing */
/* critical section */
lock = 0;
/* remainder section */
} while (true);
Synchronization Hardware – Atomic Variables
• The compare and swap() instruction is not used directly to provide mutual
exclusion. Rather, it is used as a basic building block for constructing other tools
that solve the critical-section problem.

• One such tool is an atomic variable, which provides atomic operations on basic
data types such as integers and booleans.

• Atomic variables can be used in to ensure mutual exclusion in situations where

there may be a data race.

• Most systems that support atomic variables provide special atomic data types as
well as functions for accessing and manipulating atomic variables.

• These functions are often implemented using compare and swap()

MUTEX LOCKS.
 Mutex Locks
• Previous solutions are complicated and generally inaccessible to application programmers

• OS designers build software tools to solve critical section problem

• Simplest is mutex lock

• Protect a critical section by first acquire() a lock then release() the lock
• Boolean variable indicating if lock is available or not

• Calls to acquire() and release() must be atomic

• Usually implemented via hardware atomic instructions

• But this solution requires busy waiting

• This lock therefore called a spinlock
acquire() and release()
• acquire() {
while (!available)
; /* busy wait */
available = false;
}
• release() {
available = true;
}
• do {
acquire lock
critical section
release lock
remainder section
} while (true);
SEMAPHORES.
 Semaphore
• Synchronization tool that provides more sophisticated ways (than Mutex locks) for process to synchronize their activities.

• Semaphore S – integer variable

• Can only be accessed via two indivisible (atomic) operations

• wait() and signal()

• Originally called P() and V()

• Definition of the wait() operation

wait(S) {

while (S <= 0)

; // busy wait

S--;

• Definition of the signal() operation

signal(S) {

S++;

}
 Semaphore Usage
• Counting semaphore – integer value can range over an unrestricted domain

• Binary semaphore – integer value can range only between 0 and 1

• Same as a mutex lock

• Can solve various synchronization problems

• Consider P1 and P2 that require S1 to happen before S2

Create a semaphore “synch” initialized to 0

P1:

S1;

signal(synch);

P2:

wait(synch);

S2;

• Can implement a counting semaphore S as a binary semaphore

 Semaphore Implementation
• Must guarantee that no two processes can execute the wait() and signal()
on the same semaphore at the same time

• Thus, the 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

• typedef struct{

int value;

struct process *list;

} semaphore;
Implementation with no Busy waiting (Cont.)

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

signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}
Problems with Semaphores
• Incorrect use of semaphore operations:

• signal (mutex) …. wait (mutex)

• wait (mutex) … wait (mutex)

• Omitting of wait (mutex) or signal (mutex) (or

both)

• Deadlock and starvation are possible.

 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
• Solved via priority-inheritance protocol
MONITORS
 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
• 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
 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

CLASSIC PROBLEMS OF SYNCRONIZATION.
 Classical Problems of Synchronization
• Classical problems used to test newly-proposed
synchronization schemes
• Bounded-Buffer Problem

• Readers and Writers Problem

• Dining-Philosophers Problem
BOUNDED BUFFER 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 next_produced */
...
wait(empty);
wait(mutex);
...
/* add next produced 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 next_consumed */
...
signal(mutex);
signal(empty);
...
/* consume the item in next consumed */
...
} while (true);
READERS_WRITERS PROBLEM
 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 (Cont.)
• The structure of a writer process

do {
wait(rw_mutex);
...
/* writing is performed */
...
signal(rw_mutex);
} while (true);
 Readers-Writers Problem (Cont.)
• The structure of a reader process
do {
wait(mutex);
read_count++;
if (read_count == 1)
wait(rw_mutex);
signal(mutex);
...
/* reading is performed */
...
wait(mutex);
read count--;
if (read_count == 0)
signal(rw_mutex);
signal(mutex);
} while (true);
 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
 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

• 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 this algorithm?

 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.
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;
}
}
 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

 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 – Condition Variables

• 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 (Cont.)

• The operation x.signal can be implemented as:

if (x_count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}
 Resuming Processes within a Monitor

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

executed, which should be resumed?

• FCFS frequently not adequate

• conditional-wait construct of the form x.wait(c)

• Where c is priority number

• Process with lowest number (highest priority) is scheduled next

DEADLOCK: SYSTEM MODEL
System Model
• System consists of resources
• 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 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 {P0, P1, …, Pn} of waiting processes such that
P0 is waiting for a resource that is held by P1, P1 is waiting for a resource
that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and Pn
is waiting for a resource that is held by P0.
Deadlock with Mutex Locks
• Deadlocks can occur via system calls, locking, etc.

• See example box in text page 318 for mutex

deadlock
 Resource-Allocation Graph
A set of vertices V and a set of 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 Pi → Rj

• assignment edge – directed edge Rj → Pi

 Resource-Allocation Graph (Cont.)
• Process

• Resource Type with 4 instances

• Pi requests instance of Rj
P
i
Rj
• Pi is holding an instance of Rj
P
i 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
 Methods for Handling Deadlocks
• Ensure that the system will never enter a deadlock state:
• Deadlock prevention

• Deadlock avoidence

• 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 (e.g.,

read-only files); must hold for non-sharable 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 allocated to it.
• 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 in 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
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 a priori claim maximum use

• 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 an 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

Requesti = 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 – Requesti;
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
 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

• Pi → Pj if Pi is waiting for Pj
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 [i][j] = 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
 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?

1. Priority of the process

2. How long process has computed, and how much longer to completion

3. Resources the process has used

4. Resources process needs to complete

5. How many processes will need to be terminated

6. 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