Lecture Operating systems: A concept-based approach (2/e): Chapter 11 - Dhananjay M. Dhamdhere

Chapter 11 - Deadlocks. This chapter discusses how deadlocks can arise and how an OS performs deadlock handling to ensure an absence of deadlocks, either through detection and resolution of deadlocks, or through resource allocation policies that perform deadlock prevention or deadlock avoidance.

PROPRIETARY MATERIAL. ©  2007 The McGraw­Hill Companies, Inc. All rights reserved. No part of this PowerPoint slide  may be displayed, reproduced or distributed 

in any form or by any means, without the prior written permission of the publisher, or used beyond the limited distribution to teachers and educators permitted by McGraw­Hill  for their individual course preparation. If you are a student using this PowerPoint slide, you are using it without permission. 

– A deadlock involving a set of processes D is a situation in which

* Every process P i in D is blocked on some event e i

* Event e i can be caused only by actions of some process(es) in D

* Processes wait for requested resources to be allocated to them

Resource deadlocks

– Resource request

* A process requests a resource through a system call

* The process is blocked if the resource cannot be allocated to it– Resource allocation to a process

* If the process was blocked, its state is changed to ready

* The process becomes a holder of the resource

* The resource state is changed to ‘allocated’

– Resource release

* A process releases a resource through a system call

* The OS allocates the resource to a process blocked for it, if any

Conditions for resource deadlock

conditions hold simultaneously

The resource allocation state of a system

or simply resource state, to indicate

– State of each resource in the system

– Resource allocations and pending resource requests

– Each resource in a class is called a resource unit or resource

instance

– Each resource instance has a state

Modeling the resource state

– The matrix model

* Does not impose any constraints on resource requests

 Resources, allocations and pending requests are represented

    in separate matrices

Wait-for graph (WFG)

system in which every resource class contains only one resource unit

– A Node in the graph is a process

– An edge is a wait-for relationship between processes

* A wait-for edge (P i , P j) indicates that

 Process P j holds the resource unit of a resource class

 Process P i has requested the resource and it has become blocked on it

 In essence P i waits for P j to release the resource

Resource request and allocation graph (RRAG)

– Two kinds of nodes exist in an RRAG

* A circle is a process

* A rectangle is a resource class

 Each bullet in a rectangle is one resource unit

– Edges can also be of two kinds

* An edge from a resource class to a process is a resource allocation

* An edge from a process to a resource class is a pending resource request

RRAG (left half of Part (b))

which is allocated to P1

• P2 and P3 have requested R1

Paths in WFG and RRAG

destination node of an edge is the source node of the

subsequent edge

– Consider a path P1 – Ri – P2 – Rj – P3 – Rk – P4

This path indicates that

* Process P 4 has been allocated a resource unit of R k

* Process P 3 has been allocated a resource unit of R j and awaits a

resource unit of R k, etc

– No deadlock exists because a resource unit of Rk is allocated to

* Hence it may finish using the resource and release R k

* Then P3 can use R k and so on

Another example

• What if the system contained two tapes and a

printer and three processes that used these

resources as follows:

Process Pi Process Pj Process Pk

Request a tape Request a printer Request a tape

… … …

Request a printer Request a tape

Q: Do we have a deadlock?

RRAG after all requests of the example are made

•  The printer is allocated to P j

• The units of tape are allocated to P i and P k

•  P i   has requested a printer and P j  has requested a tape

– A cycle in an RRAG is a necessary condition for a deadlock

– A cycle in an RRAG is not a sufficient condition for a deadlock

● From this and the previous example, we can conclude that

Deadlock handling approaches

– Deadlock detection and resolution

* Kernel periodically analyzes resource state

* If a deadlock exists, it aborts some processes and reallocates their resources to other processes so that there is no deadlock

– Deadlock prevention

* The kernel’s resource allocation policy ensures that the four conditions for deadlock cannot be satisfied simultaneously– Deadlock avoidance

* The kernel grants only those resource requests whose granting cannot lead to deadlocks in future

* Other requests are kept pending until they can be granted

Deadlock detection

– Allocated resources: n x r matrix

– Requested resources: n x r matrix

– Free resources: 1-D array with r elements

Deadlock detection

– A deadlock implies that

* there is no sequence of process completion, resource release, and resource allocation events through which all processes can

complete

– So the kernel simulates process completion, resource release

and resource allocation actions to check whether all processes can complete

* It is assumed that a process whose current allocation request has been granted may complete without requesting more resources

Algorithm for deadlock detection

– Input two sets of processes—Blocked and Running

* Set Blocked contains processes blocked on resource requests

* Set Running contains ready processes

– Finished is a set of finished processes; it is initially empty

– Perform following steps until set Running is empty

* Transfer a process from Running to Finished and release its resources

 This process was not blocked for a resource, so it may finish

* If all resources requested by a process in Blocked set can be granted, grant the resources and transfer the process to Running– A deadlock exists if set Blocked is empty

Deadlock resolution

among other processes such that a deadlock does not exist

– The aborted processes are called victim processes

– The cost of resolution is the cost of re-executing victim

processes

A: They should be chosen such that the overall cost of resolution is

the minimum possible

Deadlock prevention

impossible

– How to design a deadlock prevention approach?

* Consider the conditions for deadlock

* Ensure that they cannot hold simultaneously; i.e., make sure that one of them cannot arise

Approaches to  deadlock prevention

•  Each of the approaches     prevents one of the      conditions for deadlock     from arising

Resource ranking

– Numerical ranks are associated with resources

– When process Pi requests a resource Rk with rank rk

* Abort process P i if r k is ≤ the rank of some resource already

Deadlock prevention using resource ranking

Resources R1– R 5  have resource ranks 1–5, respectively

(a) P i holds resources R1 and R3 P j holds resource R5

(b) P i requests resource R 5 It is allowed to wait for it

However, when P j requests one of the resources R1–R4, it

is aborted Thus, circular waits cannot arise

Deadlock avoidance

goes from one safe resource allocation state to another

– Safe resource allocation state:

* If the system is in such a state, all processes will be able to complete their operation without deadlocks …

 … no matter how and when processes request and release their resources in future

– Unsafe resource allocation state:

* There is a possibility of a deadlock in future

Deadlock avoidance

How to check for future deadlocks?

– Ask each process to declare its maximum requirement of each resource class

– Check whether each process can get the maximum

requirements of each resource class simultaneously by some

sequence of process completion – resource release – resource allocation events

* This is done through simulation (analogous to deadlock detection)– A deadlock may arise in future if it is not the case

Q: Why?

this approach

Banker’s algorithm for a single resource class

• The system contains 10 units of a resource

• Max need: maximum need of the resource for processes P1–P3

• Allocated resources: resources allocated to processes P1–P3

• Process P1 has requested 1 more unit of the resource Should

this request be granted?

Banker’s algorithm

– Input: Sets of processes named Active and Blocked

1 Accept the next request

2 Simulate granting of the request

3 Check whether the new resource state is feasible

* i.e., whether allocated resources ≤ total resources for all classes

4 Check whether the new resource state is safe

* Find a process in Active set whose maximum requirements can be      met using free resources. Delete it from Active and simulate 

      release of  its resources  

        * Repeat until no more such processes exist in Active

5 Grant the request if set Active is empty; else keep it pending

Multi-resource Banker’s algorithm

Max need Allocated resources Total resources

Q: If process P2 requests 0 1 1 0 resources of resource classes

R –R , should the request be granted?

Deadlock avoidance by Multi-resource Banker’s algorithm

Banker’s algorithm

Q: Can P 1 or P2 be allocated resources (1, 0) in this resource state?

Banker’s algorithm

Qs: Is this state safe?

Should P1’s request for (1, 1, 0) resources be granted?

Characterization of deadlocks

deadlocks to exist in a system

– For this, we classify systems on the basis of the nature of

resource classes and resource requests made by processes

* Resource classes

 Single instance (SI): Resource class has a single resource unit

 Multiple instance (MI): Resource class has several resource units

* Resource requests

 Single request (SR): Request for 1 unit of 1 class only

 Multiple request (MR): Request for 1 unit each of several resource classes

Classification of systems

• Classification is based on nature of resource classes and resource

requests

SISR systems

deadlock in SISR systems?

– A cycle in a WFG is both a necessary and a sufficient condition

Q: Is a cycle in an RRAG necessary and sufficient?

MISR system

condition for a deadlock in an MISR system

– See the example involving three processes and a printer and a tape (slides 13 and 14)

Q: So, what is a sufficient condition?

MISR system

condition

A subgraph G’ = ( N’, E’ ) of graph G = ( N, E ) is a knot if

– For every node ni in N’: All out-edges of ni in G are included in G’ – For every path ni nj in G’, a path nj ni also exists in G’

A knot in RRAG of an MISR system

• The tape class has two instances, hence the tape node has two

out-edges

• The notion of knot requires that both out-edges of a tape node are

involved in cycles

SIMR system

•   A cycle is both a necessary and sufficient condition for a  deadlock

    Q:  Why?

MIMR system

A subgraph G’ = ( N’, E’ ) of graph G = ( N, E ) is a resource knot if

– For every resource node in N’: All out-edges of ni in G are

included in G’

– For every path ni nj in G’, a path nj ni also exists in G’

RRAG for an MIMR system

Qs: Does a deadlock exist ?

(You could complete the out-edge of R3 as you like)

Processes in a deadlock

– RRi : Set of resource classes requested by Pi

– HSk: Set of processes holding resources of resource class Rk

– KS : Set of processes in resource knots

– AS : Auxiliary set of process nodes

AS = { Pi | RRi contains Rk such that HSk is included

in (KS Ụ AS) }

D = KS Ụ AS

Processes in deadlock

Q: Form the sets KS, AS and D

Deadlock handling in practice

handling policies for different resources

– Memory: Swapping is used, hence no deadlocks

– I/O devices: All deadlock handling policies have weaknesses Hence the kernel creates virtual I/O devices for allocation

– Files and messages: Deadlock handling is not implemented

– Control blocks in the kernel: Resource ranking can be used