chapter 7: deadlocks

77
Chapter 7: Deadlocks Chapter 7: Deadlocks

Upload: others

Post on 02-Jan-2022

4 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

Page 2: Chapter 7: Deadlocks

Before we startBefore we start The project starts on November 10th 2010

Analysis due December 6th shifted !!!!y Design due December 24th shifts to Dec. 28th

Implementation due January 28th 2010 does not shift!!! Final project will be discussed with instructor on dates TBA

7.2 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 3: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection

R f D dl k Recovery from Deadlock

7.3 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 4: Chapter 7: Deadlocks

Traffic deadlockTraffic deadlock

7.4 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 5: Chapter 7: Deadlocks

Funny deadlockFunny deadlock

7.5 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 6: Chapter 7: Deadlocks

Deadlock: Game overDeadlock: Game over

7.6 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 7: Chapter 7: Deadlocks

Where do u go now?Where do u go now?

7.7 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 8: Chapter 7: Deadlocks

Another deadlockAnother deadlock

7.8 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 9: Chapter 7: Deadlocks

Good morning to you!Good morning to you!

7.9 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 10: Chapter 7: Deadlocks

DeadlocksDeadlocks

In a multiprogramming environment several processes may compete for a finite number of resourcescompete for a finite number of resources.

A process requests resources; and if the resources are not available at that time the process enters a waiting state.

Sometimes, a waiting process is never again able to change state, because the resources it has requested are held by other waiting processes. This situation is called a g pdeadlock.

The best illustration of a deadlock can be drawn from a law passed by the Kansas legislature early in the 20th century Itpassed by the Kansas legislature early in the 20th century. It said, in part: "When two trains approach each other at a crossing, both

shall come to a full stop and neither shall start up againshall come to a full stop and neither shall start up again until the other has gone.“

7.10 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 11: Chapter 7: Deadlocks

Train DeadlockTrain Deadlock

7.11 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 12: Chapter 7: Deadlocks

ResourcesResources

A system consists of a finite number of resources to be di t ib t d tidistributed among competing processes.

The resources are partitioned into several types, each consisting of some number of identical instancesconsisting of some number of identical instances. Memory space, CPU cycles, files, and I/O devices (such

as printers and DVD drives) If a system has two CPUs, then the resource type CPU

has two instances. Similarly, the resource type printer may have five instancesmay have five instances.

7.12 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 13: Chapter 7: Deadlocks

The Deadlock ProblemThe Deadlock Problem

A set of blocked processes each holding a resource and iti t i h ld b th iwaiting to acquire a resource held by another process in

the set. Example Example

System has 2 disk drives. P1 and P2 each hold one disk drive and each needs 1 2

another one. Example

semaphores A and B, initialized to 1P0 P1

wait (A); wait(B)wait (B); wait(A)

7.13 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 14: Chapter 7: Deadlocks

Bridge Crossing ExampleBridge Crossing Example

Traffic only in one direction. Each section of a bridge can be viewed as a resource.

If d dl k it b l d if b k 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 Several cars may have to be backed up if a deadlock occurs.

Starvation is possible.

7.14 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 15: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection

R f D dl k Recovery from Deadlock

7.15 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 16: Chapter 7: Deadlocks

System ModelSystem 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. If the request cannot be granted immediately (for example, if the resource is being used by another process), then the requesting process must wait until it can acquire the q g p qresource.

Use. The process can operate on the resource (for example, if th i i t th i t thif the resource is a printer, the process can print on the printer).

Release. The process releases the resource.Release. The process releases the resource. The request and release of resources are system calls.

Examples are the request() and release() device, open()

7.16 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

p q () () , p ()and close() file, and allocate() and free() memory system calls.

Page 17: Chapter 7: Deadlocks

Processes in deadlockProcesses in deadlock

A set of processes is in a deadlock state when every i th t i iti f t th t b dprocess in the set is waiting for an event that can be caused

only by another process in the set. The events with which we are mainly concerned here are The events with which we are mainly concerned here are

resource acquisition and release. The resources may be either

physical resources (for example, printers, tape drives, memory space, and CPU cycles) or l i l (f l fil h logical resources (for example, files, semaphores, and monitors).

However, other types of events may result in deadlocks. However, other types of events may result in deadlocks.

7.17 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 18: Chapter 7: Deadlocks

CDCD--RW deadlockRW deadlock

To illustrate a deadlock state, consider a system with threeCD RW d iCD-RW drives.

Suppose each of three processes holds one of these CD-RW drivesRW drives. If each process now requests another drive, the three

processes will be in a deadlock state. Each is waiting for the event "CD-RW is released," which

can be caused only by one of the other waiting processesprocesses.

The CD-RW example is a deadlock involving the same resource type.

7.18 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 19: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection

R f D dl k Recovery from Deadlock

7.19 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 20: Chapter 7: Deadlocks

Deadlock CharacterizationDeadlock CharacterizationDeadlock 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.p

No preemption: a resource can be released only voluntarily by the process holding it, after that process has

l t d it t kcompleted its task. Circular wait: there exists a set {P0, P1, …, P0} of waiting

processes such that P0 is waiting for a resource that is heldprocesses 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 P d P i iti f th t i h ld b P

7.20 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Pn, and P0 is waiting for a resource that is held by P0.

Page 21: Chapter 7: Deadlocks

ResourceResource--Allocation GraphAllocation 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 { 1, 2, , n}, g

processes in the system.

R {R R R } th t i ti f ll 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 Pig g g j i

7.21 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 22: Chapter 7: Deadlocks

ResourceResource--Allocation Graph (Cont.)Allocation Graph (Cont.)

Process

R T ith 4 i t Resource Type with 4 instances

Pi requests instance of Rj

P

Pi is holding an instance of Rj

Pi

Rj

i g j

Pi

7.22 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

iRj

Page 23: Chapter 7: Deadlocks

Example of a Resource Allocation GraphExample of a Resource Allocation Graph

7.23 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 24: Chapter 7: Deadlocks

Basic FactsBasic Facts

If graph contains no cycles no deadlock If graph contains no cycles no deadlock.

If graph contains a cycle if only one instance per resource type, then

deadlock.if l i t t if several instances per resource type, possibility of deadlock.

7.24 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 25: Chapter 7: Deadlocks

Resource Allocation Graph With A DeadlockResource Allocation Graph With A Deadlock

7.25 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 26: Chapter 7: Deadlocks

Graph With A Cycle But No DeadlockGraph With A Cycle But No Deadlock

7.26 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 27: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection

R f D dl k Recovery from Deadlock

7.27 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 28: Chapter 7: Deadlocks

Methods for Handling DeadlocksMethods for Handling Deadlocks

Ensure that the system will never enter a deadlock 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

7.28 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 29: Chapter 7: Deadlocks

From deadlock to restartFrom deadlock to restart

If a system neither ensures that a deadlock will never occur id h i f d dl k d t ti dnor provides a mechanism for deadlock detection and

recovery, then we may arrive at a situation where the system is in a deadlocked state yet has no way of recognizing what has happened.

In this case the undetected deadlock will result in deterioration of the system's performance:deterioration of the system s performance: because resources are being held by processes that

cannot run and because more and more processes, as they make

requests for resources, will enter a deadlocked state. Eventually, the system will stop functioning and will need to

be restarted manually.

7.29 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 30: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection

R f D dl k Recovery from Deadlock

7.30 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 31: Chapter 7: Deadlocks

Deadlock PreventionDeadlock Prevention For a deadlock to occur, each of the four necessary conditions

must hold. By ensuring that at least one of these conditions cannot hold we can prevent the occurrence of a deadlockcannot hold, we can prevent the occurrence of a deadlock. Deadlock-prevention algorithms, prevent deadlocks by

restraining how requests can be made.g q

7.31 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 32: Chapter 7: Deadlocks

Mutual ExclusionMutual Exclusion

Mutual Exclusion – not required for sharable resources; must hold for nonsharable resourcesmust hold for nonsharable resources. For example, a printer cannot be simultaneously

shared by several processes.y Read-only files are a good example of a sharable

resource. If several processes attempt to open a read-only file at the same time they can be grantedonly file at the same time they can be granted simultaneous access to the file.

A process never needs to wait for a sharable resource. p In general! however we cannot prevent deadlocks by

denying the mutual-exclusion condition, because some i t i i ll h blresources are intrinsically non sharable.

7.32 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 33: Chapter 7: Deadlocks

Hold and WaitHold and Wait

Hold and Wait – must guarantee that whenever a process requests a resource, it does not hold any other resources. Protocol 1: Require process to request and be allocated all its

resources before it begins execution orresources before it begins execution, or Protocol 2: Allow process to request resources only when the

process has none.

7.33 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 34: Chapter 7: Deadlocks

Hold and WaitHold and Wait

Example: consider a process that copies data from a DVD drive to a file on disk sorts the file and then prints the results to a printera file on disk, sorts the file, and then prints the results to a printer. If all resources must be requested at the beginning of the

process, then the process must initially request the DVD drive, disk file, and printer. It will hold the printer for its entire execution, even though it needs the printer only at the end.

The second method allows the process to request initially only p q y ythe DVD drive and disk file. It copies from the DVD drive to the disk and then releases both the DVD drive and the disk file. The process must then again request the disk file and the printer. After copying the disk file to the printer, it releases these two resources and terminates.

Disadvantages: Low resource utilization and possible g pstarvation.

7.34 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 35: Chapter 7: Deadlocks

No PreemptionNo Preemption If a process that is holding some resources requests another

resource that cannot be immediately allocated to it, then all yresources currently being held are released.Preempted resources are added to the list of resources for

which the process is waitingwhich 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. Alternatively, if a process requests some resources, we first

check whether they are available. If they are, we allocate them. If they are not, we check If they are, we allocate them. If they are not, we check

whether they are allocated to some other process that is waiting for additional resources.

If so we preempt the desired resources from the– If so, we preempt the desired resources from the waiting process and allocate them to the requesting process.

7.35 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 36: Chapter 7: Deadlocks

Circular waitCircular wait One way to ensure that this condition never holds is to impose a

total ordering of all resource types and to require that each t i i i d fprocess requests resources in an increasing order of

enumeration. For example if the set of resource types R includes tape drives For example, if the set of resource types R includes tape drives,

disk drives, and printers, then the function F might be defined as follows:

F (tape drive) = 1F (disk drive) = 5

F ( i t ) 12F (printer) = 12 Using the function F, a process that wants to use the tape

drive and printer at the same time must first request the tapedrive and printer at the same time must first request the tape drive and then request the printer.

Alternatively, we can require that, whenever a process requests

7.36 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

an instance of resource type Rj, it has released any resources Ri such that F(Ri) >= F(R j ).

Page 37: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection

R f D dl k Recovery from Deadlock

7.37 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 38: Chapter 7: Deadlocks

Deadlock AvoidanceDeadlock 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 ofprocess 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 il bl d ll t d d th iavailable and allocated resources, and the maximum

demands of the processes.

7.38 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 39: Chapter 7: Deadlocks

Safe StateSafe 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, …, P > of all the processes in the systems such that for each PPn> 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 < iwith j < i.

That is: If P resource needs are not immediately available then P 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, j i

execute, return allocated resources, and terminate. When Pi terminates, Pi +1 can obtain its needed resources,

and so on

7.39 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

and so on.

Page 40: Chapter 7: Deadlocks

Basic FactsBasic Facts

If a system is in safe state no deadlocks.y

If a system is in unsafe state possibility of d dl kdeadlock.

Avoidance ensure that a system will never enterAvoidance ensure that a system will never enter an unsafe state.

7.40 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 41: Chapter 7: Deadlocks

Safe, Unsafe , Deadlock State Safe, Unsafe , Deadlock State

7.41 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 42: Chapter 7: Deadlocks

ExampleExample Consider a system with 12 magnetic tape drives and three processes: P0,

P1 d P2 P P0 i 10 t d i P1 dP1, and P2. Process P0 requires 10 tape drives, process P1 may need as many as 4 tape drives, and process P2 may need up to 9 tape drives.

Suppose that, at time T0 we have:

At time T0 the system is in a safe state The sequence < P1 P0 P2> At time T0, the system is in a safe state. The sequence < P1, P0, P2> satisfies the safety condition.

The system can go from a safe state to an unsafe state. Suppose that, at time T1 P2 requests and is allocated one more tape drivetime T1, P2 requests and is allocated one more tape drive. The system is no longer in a safe state. Only process P1 can be allocated all its tape drives. Suppose it

t ll th d h 4 t f !!!returns all them and we have 4 tapes free!!! P0 may request other 5 tapes and wait P2 may request other 6 tapes and wait

7.42 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

y q p

Page 43: Chapter 7: Deadlocks

Avoidance algorithmsAvoidance algorithms

Single instance of a resource type. g yp Use a resource-allocation graph

Multiple instances of a resource type. Use the banker’s algorithm

7.43 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 44: Chapter 7: Deadlocks

ResourceResource--Allocation Graph SchemeAllocation Graph Scheme

Claim edge Pi Rj indicated that process Pj may request Claim edge Pi Rj indicated that process Pj may requestresource Rj; represented by a dashed line.

C 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 edgereconverts to a claim edge.

Resources must be claimed a priori in the system.

7.44 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 45: Chapter 7: Deadlocks

ResourceResource--Allocation GraphAllocation Graph

Suppose that process Pi requests Rjresource Rj.

The request can be granted only if converting the request edge Pi -> Rj to anconverting the request edge Pi Rj to an assignment edge Rj -> Pi does not result in the formation of a cycle in the resource-allocation graphresource-allocation graph.

Note that we check for safety by using a cycle-detection algorithm.

An algorithm for detecting a cycle in this graph requires an order of n2 operations, where n is the number of processes in thewhere n is the number of processes in the system.

7.45 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 46: Chapter 7: Deadlocks

Unsafe State In ResourceUnsafe State In Resource--Allocation GraphAllocation Graph

Suppose that P2 requests R2. Although R2 is currently free, wecannot allocate it to P2, since this action will create a cycle in the graph A cycle indicates that the system is in an unsafe state.

If P1 requests R2,and P2 requests R1 , then a deadlock will occura deadlock will occur.

7.46 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 47: Chapter 7: Deadlocks

Banker’s Algorithm (Djikstra)Banker’s Algorithm (Djikstra)

Multiple instances.p

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.

The name was chosen because the algorithm could be used in a banking system to ensure that the bank never allocatedin a banking system to ensure that the bank never allocated its available cash in such a way that it could no longer satisfy the needs of all its customers.

7.47 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 48: Chapter 7: Deadlocks

Data Structures for the Banker’s Algorithm 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.

p , yp

j

Max: n x m matrix. If Max[i,j] = k, then process Pimay request at most k instances of resource type Rj.

f Allocation: n x m matrix. If Allocation[i,j] = k then Piis currently allocated k instances of Rj.

Need: n x m matrix If Need[i j] = k then Pi may need 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].

7.48 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 49: Chapter 7: Deadlocks

Safety AlgorithmSafety Algorithm To simplify the presentation of the banker's algorithm we next To simplify the presentation of the banker s algorithm, we next

establish some notation. Let X and Y be vectors of length n. We say that X <= Y if and only if X[i] <= Y[i] for all i = 1, 2, ... , 11. For example, if X (1 7 3 2) and Y = (0 3 2 1) then Y < X Y < X if Y < X and Y /= Xif X (1,7,3,2) and Y = (0,3,2,1), then Y < X. Y < X if Y < X and Y /= X.

1. Let Work and Finish be vectors of length m and n, respectively. Initialize:

Work = AvailableFinish [i] = false for i = 0, 1, …, n- 1.

2 Find an i such that both:2. Find an i such that both: (a) Finish [i] = false(b) Needi WorkIf no such i exists, go to step 4.

3. Work = Work + AllocationiFinish[i] = trueFinish[i] = truego to step 2.

4. If Finish [i] == true for all i, then the system is in a safe state.

7.49 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

This algorithm may require an order of m x n2 operations to determine whether a state is safe.

Page 50: Chapter 7: Deadlocks

ResourceResource--Request Algorithm for Process Request Algorithm for Process PPii

We now describe the algorithm which determines if requests can be safely granted.

R t t t f P If R t [j] 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 Pi2. If Requesti Available, go to step 3. Otherwise Pimust wait, since resources are not available.

3. Pretend to allocate requested resources to Pi by modifying the state as follows:modifying the state as follows:

Available = Available – Request;Allocationi = Allocationi + Requesti;i i q i;Needi = Needi – Requesti;

If safe the resources are allocated to Pi.

7.50 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

If unsafe Pi must wait, and the old resource-allocation state is restored

Page 51: Chapter 7: Deadlocks

Example of Banker’s AlgorithmExample of Banker’s Algorithm

5 processes P0 through P4; 0 g 4

3 resource types:A (10 instances), B (5 instances), and C (7 instances).

Snapshot at time T0:Allocation Max Available

A B C A B C A B CP0 0 1 0 7 5 3 3 3 2P1 2 0 0 3 2 2 P2 3 0 2 9 0 2P3 2 1 1 2 2 2P4 0 0 2 4 3 3

7.51 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 52: Chapter 7: Deadlocks

Example (Cont.)Example (Cont.)

The content of the matrix Need is defined to be Max –AllocationAllocation.

NeedeedA B C

P0 7 4 3 0

P1 1 2 2 P2 6 0 0 P3 0 1 1P4 4 3 1

The system is in a safe state since the sequence < P1, P3, P4, P P > satisfies safety criteria

7.52 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

P2, P0> satisfies safety criteria.

Page 53: Chapter 7: Deadlocks

Example: Example: PP11 Request (1,0,2)Request (1,0,2)

Check that Request Available (that is, (1,0,2) (3,3,2) true.Allocation Need Available

A B C A B C A B C P0 0 1 0 7 4 3 2 3 0P1 3 0 2 0 2 0 P2 3 0 1 6 0 0 P3 2 1 1 0 1 1P 0 0 2 4 3 1P4 0 0 2 4 3 1

Executing safety algorithm shows that sequence < P1, P3, P4, P0, P2> satisfies safety requirementsatisfies safety requirement.

Can request for (3,3,0) by P4 be granted? No. Resources not available.

7.53 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Can request for (0,2,0) by P0 be granted? No. We go in unsafe state.

Page 54: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection

R f D dl k Recovery from Deadlock

7.54 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 55: Chapter 7: Deadlocks

Deadlock DetectionDeadlock Detection

Allow system to enter deadlock state

Detection algorithm

Recovery scheme

At this point, however we note that a detection-and-recovery scheme requires overhead that includes: not only the run-time costs of maintaining the y g

necessary information and executing the detection algorithm

but also the potential losses inherent in recovering from but also the potential losses inherent in recovering from a deadlock.

7.55 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 56: Chapter 7: Deadlocks

Single Instance of Each Resource TypeSingle Instance of Each Resource Type

Maintain wait-for graphMaintain wait for graph Nodes are processes. Pi Pj if Pi is waiting for Pj.i j i g j

Periodically invoke an algorithm that searches for a cycle in the graph If there is a c cle there e ists a deadlockthe graph. If there is a cycle, there exists a deadlock.

Complexity: An algorithm to detect a cycle in a graph Complexity: 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.

7.56 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 57: Chapter 7: Deadlocks

ResourceResource--Allocation Graph and WaitAllocation Graph and Wait--for Graphfor Graph

Resource-Allocation Graph Corresponding wait-for graph

7.57 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 58: Chapter 7: Deadlocks

Several Instances of a Resource TypeSeveral Instances of a Resource Type

Available: A vector of length m indicates the number gof available resources of each type.

All ti A t i d fi th b f 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 isof each process. If Request [ij] = k, then process Pi is requesting k more instances of resource type. Rj.

7.58 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 59: Chapter 7: Deadlocks

Detection AlgorithmDetection Algorithm

1. Let Work and Finish be vectors of length m and n, ti l I iti lirespectively Initialize:

(a) Work = Available(b) For i 1 2 n if Allocation 0 then(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( ) q i

If no such i exists, go to step 4.

7.59 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 60: Chapter 7: Deadlocks

Detection Algorithm (Cont.)Detection Algorithm (Cont.)

3 Work = Work + Allocation3. Work = Work + AllocationiFinish[i] = truego 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 , [ ] , ideadlocked.

Algorithm requires an order of O(m x n2) operations to detect whether the system is in deadlocked state.

7.60 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 61: Chapter 7: Deadlocks

Example of Detection AlgorithmExample of Detection Algorithm

Five processes P0 through P4; three resource types A (7 i t ) B (2 i t ) d C (6 i t )A (7 instances), B (2 instances), and C (6 instances).

Snapshot at time T0:Allocation Req est A ailableAllocation Request Available

A B C A B C A B CP 0 1 0 0 0 0 0 0 0P0 0 1 0 0 0 0 0 0 0P1 2 0 0 2 0 2P 3 0 3 0 0 0P2 3 0 3 0 0 0 P3 2 1 1 1 0 0 P4 0 0 2 0 0 2P4 0 0 2 0 0 2

No deadlock: Sequence <P0, P2, P3, P1, P4> will result in Finish[i] = true for all i.

7.61 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 62: Chapter 7: Deadlocks

Example (Cont.)Example (Cont.)

P2 requests an additional instance of type C.Request

A B CP0 0 0 0P1 2 0 1P2 0 0 1P3 1 0 0 P 0 0 2P4 0 0 2

State of system?C l i h ld b P b t Can reclaim resources held by process P0, but insufficient resources to fulfill other processes requests.

Deadlock exists, consisting of processes P1, P2, P3, and

7.62 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

, g p 1, 2, 3,P4.

Page 63: Chapter 7: Deadlocks

DetectionDetection--Algorithm UsageAlgorithm 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?

If detection algorithm is invoked arbitrarily, there may be many cycles in the resource graph and so we would not be able tocycles in the resource graph and so we would not be able to tell which of the many deadlocked processes “caused” the deadlock.

If deadlocks occur frequently, then the detection algorithm should be invoked frequently. Resources allocated to deadlocked processes will be idle Resources allocated to deadlocked processes will be idle

until the deadlock can be broken. In addition, the number of involved processes in the

7.63 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

, pdeadlock cycle may grow.

Page 64: Chapter 7: Deadlocks

DetectionDetection--Algorithm UsageAlgorithm Usage

Deadlocks occur only when some process makes a request th t t b t d i di t lthat cannot be granted immediately. This request may be the final request that completes a

chain of waiting processeschain of waiting processes. In the extreme, we can invoke the deadlock detection

algorithm every time a request for allocation cannot be granted immediately. In this case, we can identify not only the deadlocked set of processes but also the specific process that "caused" the deadlock.

7.64 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 65: Chapter 7: Deadlocks

DetectionDetection--Algorithm Computational OverheadAlgorithm Computational Overhead

If the deadlock-detection algorithm is invoked for every resource t thi ill i id bl h d i t tirequest, this will incur a considerable overhead in computation

time. A less expensive alternative is simply to invoke the algorithm A less expensive alternative is simply to invoke the algorithm

at less frequent intervals-for example, once per hour or whenever CPU utilization drops below 40 percent. (A deadlock eventually cripples system throughput anddeadlock eventually cripples system throughput and causes CPU utilization to drop.)

If the detection algorithm is invoked at arbitrary points in time, there may be many cycles in the resource graph. In this case, we would generally not be able to tell which of

the many deadlocked processes "caused“ the deadlockthe many deadlocked processes caused the deadlock.

7.65 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 66: Chapter 7: Deadlocks

Chapter 7: DeadlocksChapter 7: Deadlocks

The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection

R f D dl k Recovery from Deadlock

7.66 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 67: Chapter 7: Deadlocks

Deadlock recoveryDeadlock recovery

When a detection algorithm determines that a deadlock i t l lt ti il blexists, several alternatives are available. One possibility is to inform the operator that a deadlock

has occurred and to let him deal with the deadlockhas occurred and to let him deal with the deadlock manually.

Another possibility is to let the system recover from the deadlock automatically. There are two options for breaking a deadlock:

Si l t b t t– Simply to abort one or more processes to break the circular wait.

– The other is to preempt some resources fromThe other is to preempt some resources from one or more of the deadlocked processes.

7.67 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 68: Chapter 7: Deadlocks

Recovery from Deadlock: Process TerminationRecovery from Deadlock: Process Termination

Abort all deadlocked processes. This method clearly will break the deadlock cycle, but at great

expense; the deadlocked processes may have computed for a long time, and the results of these partial computations must be discarded and probably will have to be recomputed later.

Abort one process at a time until the deadlock cycle is eliminated. This method incurs considerable overhead since after each process This method incurs considerable overhead, since, after each process

is aborted, a deadlock-detection algorithm must be invoked to determine whether any processes are still deadlocked.

7.68 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 69: Chapter 7: Deadlocks

Order to abort processesOrder to abort processes

Aborting a process may not be easy. If the process was in the midst of updating a file, terminating it

will leave that file in an incorrect state. Similarly, if the process was in the midst of printing data on a y, p p g

printer, the system must reset the printer to a correct state before printing the next job.

7.69 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 70: Chapter 7: Deadlocks

Minimum cost of process abortionMinimum cost of process abortion

If the partial termination method is used, then we must determine which deadlocked process (or processes) should be terminatedwhich deadlocked process (or processes) should be terminated.

This determination is a policy decision, similar to CPU-scheduling decisions. The question is basically an economic one; we should abort those whose termination will incur the minimum cost.

Unfortunately, the term minimum cost is not a precise one. In which order should we choose to abort? 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 Resources process needs to complete. How many processes will need to be terminated. Is process interactive or batch?

7.70 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

p

Page 71: Chapter 7: Deadlocks

Recovery from Deadlock: Resource PreemptionRecovery from Deadlock: Resource Preemption

To eliminate deadlocks using resource preemption we: To eliminate deadlocks using resource preemption, we: successively preempt some resources from processes and give these resources to other processes until the deadlock

cycle is broken.

Selecting a victim minimize cost Selecting a victim – minimize cost.

Rollback – return to some safe state, restart process from that t tstate.

Starvation – same process may always be picked as victim, include number of rollback in cost factor.

7.71 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 72: Chapter 7: Deadlocks

Selecting a victim in Resource preemptionSelecting a victim in Resource preemption

Selecting a victim. Which resources and which processes are to be preempted? As in process termination, we must determine the order of

preemption to minimize cost. p p Cost factors may include such parameters

as the number of resources a deadlocked process is h ldiholding

amount of time the process has thus far consumed during its execution.

7.72 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 73: Chapter 7: Deadlocks

Rollback in Resource preemptionRollback in Resource preemption

If we preempt a resource from a process, what should be done with that process?that process? Clearly, it cannot continue with its normal execution if it is

missing some needed resource. We must roll back the process to some safe state and restart

it from that state. Since in general it is difficult to determine what a safe state is the Since, in general, it is difficult to determine what a safe state is, the

simplest solution is a total rollback: Abort the process and then restart it. Although it is more effective to roll back the process only as far

as necessary to break the deadlock, this method requires the system to keep more information about the state of all running processes.

7.73 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 74: Chapter 7: Deadlocks

Starvation in Resource preemptionStarvation in Resource preemption

How do we ensure that starvation will not occur? That is, how can we guarantee that resources will not always be

preempted from the same process? In a system where victim selection is based primarily on cost y p y

factors, it may happen that the same process is always picked as a victim.

As a result this process never completes its designated task a As a result, this process never completes its designated task, a starvation situation that must be dealt with in any practical system.

Clearly, we must ensure that a process can be picked as a victim onl a (small) finite n mber of times The most common sol tion isonly a (small) finite number of times. The most common solution is to include the number of rollbacks in the cost factor. (a kind of Aging)

7.74 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 75: Chapter 7: Deadlocks

ReadingsReadings

Silberschatz. Chapter 7.

7.75 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005

Page 76: Chapter 7: Deadlocks

End of Chapter 7End of Chapter 7

Page 77: Chapter 7: Deadlocks

What about distributed deadlocks?What about distributed deadlocks?

A good question for Master students

Orchestra

7.77 Silberschatz, Galvin and Gagne ©2005Operating System Concepts - 7th Edition, Feb 14, 2005