Chapter 6 - Deadlocks

When Do Deadlocks Occur

 Deadlocks occur when …

 processes are granted exclusive access to devices
 we refer to these devices generally as resources
 Process request resources and if resources not available at that time, the
process enters waiting state
 Sometimes a waiting process is never able to change state because
resources it has requested held by other waiting processes
 Resources

 Examples of computer resources

 Printers
 Tape drives
 Entries in OS tables (like PCB entries)
 Memory
 Database records

 Processes need access to resources in reasonable order

 Access restricted via: critical sections / mutex / semaphore
 Resources Usage Pattern

 Sequence of events required to use a resource

1. request the resource
2. use the resource
3. release the resource

 Must wait if request is denied

 Resources Usage Pattern

 A process must request a resource before using it and must release after
using it

 A process may request as many resources as it requires to carryout task

but number of resources requested may not exceed the total no of
resources available

 Can’t request three printers if system has two

 Introduction to Deadlocks

 Formal definition :
A set of processes is deadlocked if each process in the set is waiting for
an event that only another process in the set can cause.
 Usually the event is release of a currently held resource.
 None of the processes can …
 run
 release resources
 be awakened

 Permanent blocking of a set of processes that either compete for system

resources or communicate with each other
 No Efficient solution
 Involve conflicting needs for resources by two or more processes
 Introduction to Deadlocks

 Resources may be either physical resources like printers, tape

drives, memory space and CPU cycles

 Or logical resources like files, semaphores

 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.
 P1 and P2 each hold one disk drive and each needs 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.
 Consumable Resources

 Description:
 Created (produced) and destroyed (consumed) by a process
 Examples:
 Interrupts, signals, messages, and information in I/O buffers
 Deadlock:
 May occur if a Receive message is blocking
 May take a rare combination of events to cause deadlock
 Consumable Resource Example

 Deadlock occurs if receive is blocking

P1 P2
... ...
Receive(P2); Receive(P1);
... ...
Send(P2); Send(P1);
 System Model - Reusable 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 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.
 Necessary Conditions for Deadlock

 1) Mutual exclusion:
 One process hold a resource in a non-sharable mode. Other processes
requesting resource must wait for resource to be released.

 2) Hold-and-wait:
 a process must hold at least one allocated resource while awaiting other
resources (one or more) held by other processes.
 Necessary Conditions for Deadlock

 3) No preemption:
 no resource can be forcibly removed from a process holding it. That is,
resources are voluntarily released by the process holding it.

 4) Circular wait
 a closed chain of processes exists, such that each process holds at least
one resource needed by the next process in the chain
 Modeling Deadlock with Graphs

 Process == circle, Resource == square

 resource R assigned to process A
 process B is requesting/waiting for resource S
 process C and D are in deadlock over resources T and U
Using Resource Allocation Graph
A B C
How deadlock can be avoided

(o) (p) (q)

 Resource-Allocation Graph

Deadlocks described more precisely in terms of directed graph called

system resource allocation graph

This graph consists of 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.
 Resource-Allocation Graph

 A directed edge from process Pi to resource type Rj is denoted by

Pi  Rj . It signifies that process Pi has requested an instance of
resource type Rj and is currently waiting for that resource. It is
called a Request Edge.

 A directed edge from resource type Rj to process Pi is denoted

by Rj  Pi . It signifies that an instance of resource type Rj has
been allocated to process Pi. It is called a Assignment Edge.
 Resource-Allocation Graph (Cont.)

 Process

 Resource Type with 4 instances

 Pi requests instance of Rj

Pi
Rj
 Pi is holding an instance of Rj

Pi
Rj
 Example of a Resource Allocation Graph

 When process Pi requests an instance of resource type Rj, a

request edge is inserted in the resource allocation graph

 When this request can be fulfilled, the request edge is

instantaneously transformed to an assignment edge

 When process no longer needs access to resource, it releases the

resource and as a result assignment edge is deleted
Example of a Resource Allocation Graph

Resource Instances are

One instance of resource type R1
Two instance of resource type R2
One instance of resource type R3
Three instance of resource type R4
Example of a Resource Allocation Graph

Process P1 is holding an instance of

resource type R2 and is waiting for an
instance of resource type R1

Process P2 is holding an instance of

resource type R1 and instance of R2 and is
waiting for an instance of resource type R3

Process P3 is holding an instance of R3

Resource Allocation Graph With A Deadlock

Suppose Process P3 request an instance of

resource type R2. Since no resource
instance is currently available, a request
edge P3 R2 is added to the graph.
With A Deadlock

Processes P1, P2 and

P3 are deadlocked.

Process P2 is waiting
For the resource R3
Which is held by process
P3.

Process P3 is waiting for

Either process P1 or
Process P2 to release
Resource R2.

In addition process P1 is
Waiting for process P2 to
Release resource R1
Graph With A Cycle But No Deadlock

Observe that process P4 may release

its instance of resource type R2. That
resource can than be allocated to P3,
breaking the cycle.

In short if the resource allocation

graph doesn't have a cycle then the
system is not in a deadlocked state
 Method for Handling Deadlocks

We can deal with deadlock in one of three ways

 Can use a protocol to prevent or avoid deadlocks, ensuring that

the system will never enter a deadlock state
 Can allow the system to enter deadlock state, detect it and
recovery
 Can ignore the problem altogether and pretend that deadlocks
never occur in the system
 Approaches to Deadlock Handling
 Ensure system never enters a deadlocked state: Use either:
 deadlock prevention scheme - ensure that at least one of the
necessary conditions cannot hold.
 deadlock avoidance scheme - requires the OS know in
advance the resource usage requirements of all processes.
Then for each request the OS decides if it could lead to a
deadlock before granting.
 Allow the system to enter a deadlock state and then recover.
 system implements an algorithm for deadlock detection, if so
then recover
 Assume deadlocks never occur in the system
 used by most operating systems, including UNIX.
 Deadlock Prevention

 Restrain ways a request can be made:

 Mutual Exclusion - – not required for sharable resources; must hold
for non-sharable resources. Printer cannot be simultaneously shared
by several processes. Sharable resources in contrast don’t require
mutual exclusion hence cannot be involved in deadlock. Read-only
files are good example. Several processes can be granted
simultaneous access to file

 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 - Indirect

 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

 Require system has a prior information

 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 and Unsafe States

 The “State” of the system includes

 How many resources are allocated to each process
 What is the maximum number of resources a process
could request
 How many are available
 A state is Safe if
 It is not deadlocked
 There exists a scheduling order in which all processes
run to completion.
 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 safe sequence of all processes.
 Sequence <P1, P2, …, Pn> is safe if 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.
 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

Example: Class Work

 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
 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
Unsafe State In Resource-Allocation Graph