2 Program Process Abstract Computing Environment File Manager Memory Manager Device Manager Protection Deadlock Synchronization Process Description Process.

Slides:



Advertisements
Similar presentations
Chapter 7: Deadlocks.
Advertisements

Chapter 7: Deadlocks.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 7: Deadlocks.
7.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 7: Deadlocks.
Deadlocks CS 3100 Deadlocks1. The Deadlock Problem A set of blocked processes each holding a resource and waiting to acquire a resource held by another.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 8: Deadlocks System Model Deadlock Characterization Methods for Handling Deadlocks.
10 Deadlock Example Process 1 Process 2 Resource 1 Resource 2 Process holds the resource Process requests the resource.
Chapter 7. Deadlocks.
1 Chapter 7: Deadlock. 2 The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance.
Chapter 8: Deadlocks System Model Deadlock Characterization
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts - 7 th Edition, Feb 14, 2005 Chapter 7: Deadlocks The Deadlock.
Deadlock. Example Process 1 Process 2 Resource 1 Resource 2.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 7: Deadlocks.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 7: Deadlocks.
Deadlocks Gordon College Stephen Brinton. Deadlock Overview The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks.
1 School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Ch 7: Deadlock Dr. Mohamed Hefeeda.
What we will cover…  The Deadlock Problem  System Model  Deadlock Characterization  Methods for Handling Deadlocks  Deadlock Prevention  Deadlock.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts - 7 th Edition, Feb 14, 2005 Objectives Understand the Deadlock.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Deadlocks.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 8: Deadlocks System Model Deadlock Characterization Methods for Handling Deadlocks.
System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention, Avoidance, and Detection Recovering from Deadlock Combined Approach.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 7: Deadlocks.
Chapter 7 Deadlocks. 7.2 Modified By Dr. Khaled Wassif Operating System Concepts – 7 th Edition Silberschatz, Galvin and Gagne ©2005 Chapter 7: Deadlocks.
Cosc 4740 Chapter 6, Part 4 Deadlocks. The Deadlock Problem A set of blocked processes each holding a resource and waiting to acquire a resource held.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-6 Deadlocks Department of Computer Science and Software Engineering.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 AE4B33OSS Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock Characterization.
CHAPTER 8: DEADLOCKS System Model Deadlock Characterization
 The Deadlock Problem  System Model  Deadlock Characterization  Methods for Handling Deadlocks  Deadlock Prevention  Deadlock Avoidance  Deadlock.
Dr. Kalpakis CMSC 421, Operating Systems Deadlocks.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks System Model Deadlock Characterization Methods.
Lecture 12 Handling Deadlock – Prevention, avoidance and detection.
Mi-Jung Choi Dept. of Computer and Science Silberschatz, Galvin and Gagne ©2006 Operating System Principles Chapter 7: Deadlocks.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 7: Deadlocks.
Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill Technology Education Lecture 7 Operating Systems.
Chapter 8 Deadlocks. Objective System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection.
Chapter 7: Deadlocks. 7.2CSCI 380 – Operating Systems Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock Characterization Methods for Handling.
7.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock Characterization.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
CS307 Operating Systems Deadlocks Fan Wu Department of Computer Science and Engineering Shanghai Jiao Tong University Spring 2012.
國立台灣大學 資訊工程學系 Chapter 7: Deadlocks. 資工系網媒所 NEWS 實驗室 Chapter Objectives To develop a description of deadlocks, which prevent sets of concurrent processes.
Chap 7 Deadlocks. Chapter Objectives To develop a description of deadlocks, which prevent sets of concurrent processes from completing their tasks To.
1 CS.217 Operating System By Ajarn..Sutapart Sappajak,METC,MSIT Chapter 6 Deadlocks Slide 1 Chapter 6 Deadlocks.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 8: Deadlocks System Model Deadlock Characterization Methods for Handling Deadlocks.
Deadlocks Introduction to Operating Systems: Module 7.
7.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 7: Deadlocks.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter Objectives To develop a description of deadlocks, which.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
7.1 CSE Department MAITSandeep Tayal 7: Deadlocks System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 7: Deadlocks.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts - 7 th Edition, Feb 14, 2005 Chapter 7: Deadlocks The Deadlock.
Slide 10-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 10.
CSE Operating System Principles Deadlocks. CSE – Operating System Principles2 Overview System Model Deadlock Characterization Methods for.
Chapter 7: Deadlocks. The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 7: Deadlocks.
Chapter 7: Deadlocks.
OPERATING SYSTEM CONCEPTS AND PRACTISE
Chapter 7: Deadlocks.
Chapter 7: Deadlocks.
Outline Announcement Deadlock Deadlock definition - review
G.Anuradha Ref:- Galvin
Chapter 7: Deadlocks.
Outline Deadlocks, dead lock prevention, avoidance.
Deadlock Prevention Restrain the ways request can be made.
Chapter 7: Deadlocks.
Chapter 7: Deadlocks.
Chapter 7: Deadlocks.
Presentation transcript:

2 Program Process Abstract Computing Environment File Manager Memory Manager Device Manager Protection Deadlock Synchronization Process Description Process Description CPU Other H/W Scheduler Resource Manager Resource Manager Resource Manager Resource Manager Resource Manager Resource Manager Memory Devices Process Mgr

 Let S and Q be two semaphores initialized to 1 P 0 P 1 P ( S ); P ( Q ); P ( Q ); P ( S );  V( S );V( Q ); V( Q )V( S );  What is the potential problem?  How could we overcome this problem if we want to have least constraints on the programmers? 3

 Kansas State legislature  “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other is gone” 4

 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. 5

6

 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 tape drives, one CD-ROM and one DAT drive.  P1 and P2 each hold one tape drive and each needs another one. 7

8

 Semaphore example  semaphores A and B, initialized to 1 P 0 P 1 P(A);P(B); P(B);P(A);  Message deadlock example  Process A { receive(B, msg); send(B, msg): }  Process B { receive(A, msg); send(A, msg): }  Could result from a message being lost 9

10 Process 1 Process 2 Resource 1 Resource 2 Deadlock Examples – cont. Process holds resource Process requests resource

11 Process 1 Process 2 Process 3 Resource 1 Resource 2 Resource 3 Process holds resource Process requests resource

12 Application Process Application Process Resource Manager Resource Manager Memory Resource Memory Resource Disk Block Resource Disk Block Resource Process holds resource Process requests resource Deadlock can occur even if one of the processes is executing OS code!

 Deadlock can arise if four conditions hold simultaneously  Mutual exclusion  Hold and wait:  No preemption  Circular wait 13

 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. 14

 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 {P 0, P 1, …, P n } of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2, …, P n–1 is waiting for a resource that is held by P n, and P n is waiting for a resource that is held by P 0. 15

 P = {p 1, p 2, …, p n } be a set of processes  R = {R 1, R 2, …, R m } be a set of resources  c j = number of units of R j in the system  S = {S 0, S 1, …} be a set of states representing the assignment of R j to p i  State changes when processes take action  This allows us to identify a deadlock situation in the operating system 16

17 R = {R j | 0  j < m} = resource types C = {c j  0 |  R j  R (0  j < m)} = units of R j available Reusable resource: After a unit of the resource has been allocated, it must ultimately be released back to the system. E.g., CPU, primary memory, disk space, … The maximum value for c j is the number of units of that resource Consumable resource: There is no need to release a resource after it has been acquired. E.g., a message, input data, … Notice that c j is unbounded. Resource: Anything that a process can request, then be blocked because that thing is not available.

18 There is a resource manager, Mgr(R j ) for every R j Mgr(R j ) Process p i can only request n i  c j units of reusable R j p i can request unbounded # of units of consumable R j Process p i can request units of R j if it is currently running request Mgr(R j ) can allocate units of R j to p i allocate

19 Process Resource Manager Process Blocked Processes Resource Pool request() release() Policy

 In most cases, we assume that each process utilizes a resource as follows  request  If the requested resources are not available, the calling process will be blocked  use  release  Which implies that we are dealing with reusable resources 20

 The system changes state because of the action of some process, p i  There are three pertinent actions:  Request (“r i ”): request one or more units of a resource  Allocation (“a i ”): All outstanding requests from a process for a given resource are satisfied  Deallocation (“d i ”): The process releases units of a resource 21 SjSj SkSk xixi

 Want to define deadlock in terms of patterns of transitions  Define: p i is blocked in S j if p i cannot cause a transition out of S j 22 SjSj r3r3 a1a1 r1r1 p 2 is blocked in S j

 If p i is blocked in S j, and will also be blocked in every S k reachable from S j, then p i is deadlocked  S j is called a deadlock state 23

24 State diagram of one process with one resource of two units - Can request one unit at a time - Progresses from S 0 by requesting one unit - Progresses from S 1 by acquiring the unit - From S 2 can either relinquish the unit or ask for another unit ra d S0S0 S1S1 S2S2 S3S3 S4S4 ra d

 Extend this to two processes competing for two units of the single resource type  Process may request only one unit at a time  State diagram in previous slide must be replicated and copies combined to describe all the system states  Those states not possible have been removed 25

26 r0r0 a0a0 d0d0 S 00 S 10 S 20 S 30 S 40 r0r0 a0a0 d0d0 r0r0 a0a0 d0d0 S 01 S 11 S 21 S 31 S 41 r0r0 a0a0 d0d0 r0r0 a0a0 d0d0 S 02 S 12 S 22 S 32 r0r0 r0r0 a0a0 d0d0 S 03 S 13 S 23 S 33 r0r0 S 04 S 14 r0r0 r1r1 r1r1 r1r1 r1r1 r1r1 r1r1 r1r1 r1r1 a1a1 a1a1 a1a1 a1a1 a1a1 a1a1 d1d1 d1d1 d1d1 d1d1 d1d1 d1d1 r1r1 State S 33 is a deadlock state – WHY?

 Three ways  Prevention  place restrictions on resource requests to make deadlock impossible  Avoidance  plan ahead to avoid deadlock.  Recovery  Check for deadlock (periodically or sporadically) and recover from it  Manual intervention (the ad hoc approach)  Reboot the machine if it seems too slow 27

 Necessary conditions for deadlock  Mutual exclusion  Hold and wait  Circular waiting  No preemption  Ensure that at least one of the necessary conditions is false at all times 28

 Not required for sharable resources  MUST hold for nonsharable resources 29

 Need to be sure a process does not hold one resource while requesting another  Approach 1: Force a process to request all resources it needs at one time  Approach 2: If a process needs to acquire a new resource, it must first release all resources it holds, then reacquire all it needs  What does this say about state transition diagrams? 30

31 - Requesting all resources before starting

32 - Release of all resources before requesting more

 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. 33

 Results in poor utilization of resources  Can lead to starvation due to resource unavailability 34

 Occurs when a set of n processes that hold units of a set of n different resources  Impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration  Semaphore example  semaphores A and B, initialized to 1 P 0 P 1 wait (A);wait(A) wait (B);wait(B) 35

 Have a situation in which there are K processes holding units of K resources 36 RP RP P holds R P requests R RiRi PiPi

 There is a cycle in the graph of processes and resources  Choose a resource request strategy by which no cycle will be introduced  Total order on all resources, then can only ask for R j if R i < R j for all R i the process is currently holding 37

 Implementing this strategy  Require that each process requests resources in an increasing order of the associated numbers  A process can request instances of type R i initially  After that, the process can only request instances of resource type R j if F(R j ) > F(R i ), where F(R i ) and F(R j ) are the associated integer number  It several instances of the same resource type are needed, all of them must be requested in a single request 38

 Implementation – continued  Whenever a process requests an instance of resource type R j, it must first release all the resources R i, such that F(R i )  F(R j )  Circular wait cannot hold if a total ordering is imposed  Can be shown by contradiction 39

 This is how we noticed an easy solution for the dining philosophers problem  Put a total order on all forks  Require that philosopher 4 become a “left-handed” philosopher (pick up the forks in a different order than the rest) 40

philosopher(int i) { while (TRUE) {... /* Thinking */ P(fork[i]);/* Pick up left fork */ P(fork[(i+1) mod 5];/* Pick up right fork */ eat(); V(fork[(i+1) mod 5]; V(fork[i]); } philosopher4() { while (TRUE) {... /* Thinking */ P(fork[0]);/* Pick up right fork */ P(fork[4];/* Pick up left fork */ eat(); V(fork[4]; V(fork[0]); } 41

 Allow a process to time-out on a blocked request -- withdrawing the request if it fails  r = request resource  w = withdraw request  d = release or deallocate resource 42 SiSi ruru dvdv ruru SjSj SkSk wuwu

 No guarantee that this technique will be effective  System may come to set of states where a set of processes is polling for resources held by other processes in the set  Livelock, since there are transitions in the state diagram (so no deadlock), but none of these transitions are effective in the long run 43

 Define a model of system states, then choose a strategy that will guarantee that the system will not go to a deadlock state  Requires extra information, e.g., the maximum claim for each process  Allows resource manager to see the worst case that could happen, then to allow transitions based on that knowledge 44

 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 45

 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 is safe if for each P i, the resources that P i can still request can be satisfied by currently available resources + resources held by all the P j, with j < i.  If P i resource needs are not immediately available, then P i can wait until all P j have finished.  When P j is finished, P i can obtain needed resources, execute, return allocated resources, and terminate.  When P i terminates, P i+1 can obtain its needed resources, and so on. 46

 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. 47

 It is a worst case analysis  If every process were to request its maximum claim, there would be a sequence of allocations and deallocations that could enable the system to satisfy every process’s request in some order  It does not mean that the system must have enough resources to simultaneously meet all the maximum claims 48

49 Normal Execution Request Max Claim Execute, then release No Yes Likely to be in a safe state Probability of being in unsafe state increases

50 Normal Execution Request Max Claim Execute, then release No Yes Suppose all processes take “yes” branch Avoidance strategy is to allow this to happen, yet still be safe

51 I Safe States Unsafe States Deadlock States Disallow

 Note that a system could run in an unsafe state yet not enter a deadlock state  The system may not be able to guarantee that every process could execute its maximum claim, but some processes may not ask for their maximum until the system returns to a safe state, hence avoiding a deadlock  An unsafe state does not mean the system is in deadlock or even close – it merely means the resource manager cannot guarantee anything, and the resulting states will be determined only by the actions of the processes 52

 Best known of avoidance strategies  Modeled after lending policies used by banks  Each new process entering system declares the maximum use of resources it may need.  When a process requests a resource it may have to wait (until system in a safe state).  When a process gets all its resources it must return them in a finite amount of time. 53

 Available  Vector of length m. If available [j] = k, there are k instances of resource type R j available.  Max  n x m matrix. If Max [i,j] = k, then process P i may request at most k instances of resource type R j.  Allocation  n x m matrix. If Allocation[i,j] = k then P i is currently allocated k instances of R j.  Need  n x m matrix. If Need[i,j] = k, then P i may need k more instances of R j to complete its task.  Need [i,j] = Max[i,j] – Allocation [i,j] 54 Let n = number of processes, and m = number of resources types.

1. Let Work and Finish be vectors of length m and n, respectively. Initialize: Work := Available Finish [ i ] = false for i - 1, 2, 3, …, n. 2.Find an i such that both: (a) Finish [ i ] = false (b) Need i  Work If no such i exists, go to step Work := Work + Allocation i Finish [ i ] := true go to step 2. 4.If Finish [ i ] = true for all i, then the system is in a safe state. 55

 5 processes P 0 through P 4 ; 3 resource types A (10 instances), B (5 instances), and C (7 instances).  Snapshot at time T 0 : AllocationMaxAvailable A B CA B C A B C P P P P P

 The content of the matrix. Need is defined to be Max – Allocation. AllocationNeedAvailable Work A B CA B C A B C A B C P P P P P  The system is in a safe state since the sequence satisfies safety criteria. 57

Request i = request vector for process P i. If Request i [ j ] = k then process P i wants k instances of resource type R j. 1.If Request i  Need i go to step 2. Otherwise, raise error condition, since process has exceeded its maximum claim. 2.If Request i  Available, go to step 3. Otherwise P i must wait, since resources are not available. 3.Pretend to allocate requested resources to P i by modifying the state as follows: Available := Available – Request i ; Allocation i := Allocation i + Request i ; Need i := Need i – Request i;;  If safe  the resources are allocated to P i.  If unsafe  P i must wait, and the old resource-allocation state is restored 58

 Check that Request  Available (that is, (1,0,2)  (3,3,2)  true.) AllocationNeedAvailable A B CA B CA B C P P P P P  Executing safety algorithm shows that sequence satisfies safety requirement. 59

AllocationNeedAvailable A B CA B CA B C P P P P P  Can an additional request for (3,3,0) by P 4 be granted?  Can an additional request for (0,2,0) by P 0 be granted? 60

Assume n processes and m resources:  Let maxc[i, j] be the maximum claim for R j by p i  Let alloc[i, j] be the number of units of R j held by p i  Let c i be the number of units of each resource R i  Can always compute  avail[j] = c j -  0  i  n alloc[i,j]  The number of available units of R j  Should be able to determine if the state is safe or not using this info 61

1. Copy the alloc[i,j] table to alloc’[i,j] 2. Given C, maxc and alloc’, compute avail vector 3. Find p i such that maxc[i,j] - alloc’[i,j]  avail[j] for 0  j < m and 0  i < n.  If no such p i exists, the state is unsafe  If alloc’[i,j] is 0 for all i and j, the state is safe 4. Set alloc’[i,j] to 0; deallocate all resources held by p i ; go to Step 2 62

63 Example ProcessR 0 R 1 R 2 R 3 p p p p p Maximum Claim ProcessR 0 R 1 R 2 R 3 p p p p p Sum7375 Allocated Resources C = Compute total allocated Determine available units avail = = Can anyone’s maxc be met? maxc[2,0]-alloc’[2,0] = 5-4 = 1  1 = avail[0] maxc[2,1]-alloc’[2,1] = 1-0 = 1  2 = avail[1] maxc[2,2]-alloc’[2,2] = 0-0 = 0  2 = avail[2] maxc[2,3]-alloc’[2,3] = 5-3 = 2  2 = avail[3] P 2 can exercise max claim avail[0] = avail[0]+alloc’[2,0] = 1+4 = 5 avail[1] = avail[1]+alloc’[2,1] = 2+0 = 2 avail[2] = avail[2]+alloc’[2,2] = 2+0 = 2 avail[3] = avail[3]+alloc’[2,3] = 2+3 = 5

64 Example ProcessR 0 R 1 R 2 R 3 p p p p p Maximum Claim ProcessR 0 R 1 R 2 R 3 p p p p p Sum3372 Allocated Resources C = Compute total allocated Determine available units avail = = Can anyone’s maxc be met? maxc[4,0]-alloc’[4,0] = 5-1 = 4  5 = avail[0] maxc[4,1]-alloc’[4,1] = 0-0 = 0  2 = avail[1] maxc[4,2]-alloc’[4,2] = 3-3 = 0  2 = avail[2] maxc[4,3]-alloc’[4,3] = 3-0 = 3  5 = avail[3] P 4 can exercise max claim avail[0] = avail[0]+alloc’[4,0] = 5+1 = 6 avail[1] = avail[1]+alloc’[4,1] = 2+0 = 2 avail[2] = avail[2]+alloc’[4,2] = 2+3 = 5 avail[3] = avail[3]+alloc’[4,3] = 5+0 = 5

65 Example ProcessR 0 R 1 R 2 R 3 p p p p p Maximum Claim ProcessR 0 R 1 R 2 R 3 p p p p p Sum2142 Allocated Resources C = Compute total allocated Determine available units avail = = Can anyone’s maxc be met? (Yes, any of them can)

 Allow system to enter deadlock state  Detection algorithm  Recovery scheme 66

 Check for deadlock (periodically or sporadically), then recover  Can be far more aggressive with allocation  No maximum claim, no safe/unsafe states  Differentiate between  Serially reusable resources: A unit must be allocated before being released  Consumable resources: Never release acquired resources; resource count is number currently available 67

 Available: A vector of length m indicates the number of available resources of each type.  Allocation: An n x m matrix defines the number of resources of each type currently allocated to each process.  Request: An n x m matrix indicates the current request of each process. If Request [ ij ] = k, then process P i is requesting k more instances of resource type. R j. 68

1. Let Work and Finish be vectors of length m and n, respectively Initialize: (a) Work := Available (b)For i = 1,2, …, n, if Allocation i  0, then Finish [i] := false;otherwise, Finish [i] := true. 2. Find an index i such that both: (a) Finish [ i ] = false (b) Request i  Work If no such i exists, go to step (a) Work := Work + Allocation i ; (b) Finish [ i ] := true; go to step If Finish [ i ] = false, for some i, 1  i  n, then the system is in deadlock state. Moreover, if Finish [ i ] = false, then P i is deadlocked. 69 Algorithm requires an order of m x n 2 operations to detect whether the system is in deadlocked state.

 Five processes P 0 through P 4 ; three resource types A (7 instances), B (2 instances), and C (6 instances).  Snapshot at time T 0 : AllocationRequestAvailable A B C A B C A B C P P P P P  Sequence will result in Finish [ i ] = true for all i. 70

 P 2 requests an additional instance of type C. Allocation Request Available A B C A B C A B C P P P P P  State of system?  Can reclaim resources held by process P 0, but insufficient resources to fulfill other processes; requests.  Deadlock exists, consisting of processes P 1, P 2, P 3, and P 4. 71

 Micro model to describe a single state  A directed graph such that  n+m nodes represent n processes and m resources  Nodes = {p 0, p 1, …, p n }  {R 1, R 2, …, R m }  Edges connect p i to R j, or R j to p i  (p i, R j ) is a request edge for one unit of R j  (R j, p i ) is an assignment edge of one unit of R j  For each R j there is a count, c j of units Rj  Graphically represented by tokens inside R j  Number of units of R j allocated to p i plus the number requested by p i cannot exceed c j 72

73 P holds one unit of R A Deadlock State P requests one unit of R R R p p

74 Example Not a Deadlock StateNo Cycle in the Graph

 In S j, p i is allowed to request q  c h units of R h, provided p i has no outstanding requests.  S j  S k, where the RRG for S k is derived from S j by adding q request edges from p i to R h 75 RhRh pipi RhRh pipi State S j State S k p i request q units of R h q edges

 In S j, p i is allowed to acquire units of R h, iff there is (p i, R h ) in the graph, and all can be satisfied.  S j  S k, where the RRG for S k is derived from S j by changing each request edge to an assignment edge. 76 RhRh pipi RhRh pipi State S j State S k p i acquires units of R h

 In S j, p i is allowed to release units of R h, iff there is (R h, p i ) in the graph, and there is no request edge from p i.  S j  S k, where the RRG for S k is derived from S j by deleting all assignment edges. 77 RhRh pipi RhRh pipi State S j State S k p i releases units of R h

78 p0p0 p1p1 S 00

79 Example p0p0 p1p1 p0p0 p1p1 S 00 S 01

80 p0p0 p1p1 p0p0 p0p0 p1p1 p1p1 S 00 S 01 S 11 Example

81 p0p0 p1p1 p0p0 p0p0 p0p0 p1p1 p1p1 p1p1 S 00 S 01 S 11 S 21 Example

82 p0p0 p1p1 p0p0 p0p0 p0p0 p0p0 p1p1 p1p1 p1p1 p1p1 S 00 S 01 S 11 S 21 S 22 Example

83 p0p0 p1p1 p0p0 p0p0 p0p0 p0p0 p0p0 p1p1 p1p1 p1p1 p1p1 p1p1 S 00 S 01 S 11 S 21 S 22 S Example

 Deadlock state if there is no sequence of transitions unblocking every process  A RRG represents a state; can analyze the RRG to determine if there is a sequence  A graph reduction represents the (optimal) action of an unblocked process. Can reduce by p i if  p i is not blocked  p i has no request edges, and there are (R j, p i ) in the RRG 84

 Transforms RRG to another RRG with all assignment edges into p i removed  Represents p i releasing the resources it holds 85 pipi pipi Reducing by p i

 A RRG is completely reducible if there a sequence of reductions that leads to a RRG with no edges  A state is a deadlock state if and only if the RRG is not completely reducible. 86

87 p0p0 p1p1 p2p2 p0p0 p1p1 p2p2 p0p0 p1p1 p2p2 p0p0 p1p1 p2p2 A B C

 Three processes P 0 through P 2 ; three resource types A (2 instances), B (2 instances), and C (1 instance).  Snapshot at time T 0 : Allocation RequestAvailable A B C A B C A B C P P P

89 Example RRG Allocation RequestAvailable A B C A B C A B C P P P p0p0 p1p1 p2p2 A B C

 Number of units varies, have producers/consumers  Nodes = {p 0, p 1, …, p n }  {R 1, R 2, …, R m }  Edges connect p i to R j, or R j to p i  (p i, R j ) is a request edge for one unit of R j  (R j, p i ) is an producer edge (must have at least one producer for each R j )  For each R j there is a count, w j of units R j 90

91 State Transitions due to Request In S j, p i is allowed to request any number of units of R h, provided p i has no outstanding requests. S j  S k, where the RRG for S k is derived from Sj by adding q request edges from p i to R h RhRh pipi RhRh pipi State S j State S k p i request q units of R h q edges

92 State Transition for Acquire In S j, p i is allowed to acquire units of R h, iff there is (p i, R h ) in the graph, and all can be satisfied. S j  S k, where the RRG for S k is derived from Sj by deleting each request edge and decrementing w h. RhRh pipi RhRh pipi State S j State S k p i acquires units of R h

93 State Transition for Release In S j, p i is allowed to release units of R h, iff there is (R h, p i ) in the graph, and there is no request edge from p i. S j  S k, where the RRG for S k is derived from S j by incrementing w h. RhRh pipi RhRh pipi State S j State S k p i releases 2 units of R h

94 Example p0p0 p1p1 p0p0 p1p1 p0p0 p1p1 p0p0 p1p1 p0p0 p1p1

 May have a CRG that is not completely reducible, but it is not a deadlock state  For each process:  Find at least one sequence which leaves each process unblocked.  There may be different sequences for different processes -- not necessarily an efficient approach 95

96 Deadlock Detection May have a CRG that is not completely reducible, but it is not a deadlock state Only need to find sequences, which leave each process unblocked. p0p0 p1p1

97 Deadlock Detection May have a CRG that is not completely reducible, but it is not a deadlock state Only need to find a set of sequences, which leaves each process unblocked.

 Have consumable and reusable resources  Apply consumable reductions to consumables, and reusable reductions to reusables  See Figure

99 Reusable Consumable p0p0 R2R2 R1R1 R0R0 p3p3 p2p2 p1p1 Not in Fig 10.30

100 GRG Example (Fig 10.30) Reusable Consumable p0p0 R2R2 R1R1 R0R0 p3p3 p2p2 p1p1 Reduce by p 3

101 GRG Example (Fig 10.30) Reusable Consumable p0p0 R2R2 R1R1 R0R0 p3p3 p2p2 p1p1 Reduce by p 0 

 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. 102

 No magic here  Choose a blocked process  Preempt it (releasing its resources)  Run the detection algorithm  Iterate if until the state is not a deadlock state 103

 Abort all deadlocked processes.  Abort one process at a time until the deadlock cycle is eliminated.  In which order should we choose to abort?  Priority of the process.  How long process has computed, and how much longer to completion.  Resources the process has used.  Resources process needs to complete.  How many processes will need to be terminated.  Is process interactive or batch? 104

 Selecting a victim – minimize cost.  Rollback – return to some safe state, restart process from that state.  Starvation – same process may always be picked as victim, include number of rollback in cost factor. 105

 Combine the three basic approaches  prevention  avoidance  detection  Allowing the use of the optimal approach for each of resources in the system.  Partition resources into hierarchically ordered classes.  Use most appropriate technique for handling deadlocks within each class. 106