© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Deadlocks II

© Janice Regan, CMPT 300, May Resource allocation denial: deadlock avoidance strategy  When a process makes a request for one or more resources  Update the state of the system assuming the requests are granted  Determine if the resulting state is a safe state If so grant the request for resources Otherwise block the process until it is safe to grant the request

© Janice Regan, CMPT 300, May An example system: starting state

© Janice Regan, CMPT 300, May Request to check for safety  Assume the starting state is a safe state (left to student to demonstrate)  Process 2 is now requesting 2 more of resource 1 and 1 more of resource 3  Do we grant this request? Might this request cause deadlock?  Step 1: Calculate the state of the system if this request is filled  Step 2: determine if the new state is a safe state, use the bankers algorithm

© Janice Regan, CMPT 300, May An example system: new state

© Janice Regan, CMPT 300, May Bankers algorithm: preliminaries  To determine if the new state is a safe state need to compare two vectors.  One vector will be row L in the matrix (R-C) of unmet resource needs  The other vector will be the available resources vector A  When is (R-C) L < A IF (R Lk –C Lk ) <= A k for all k

© Janice Regan, CMPT 300, May Bankers algorithm  To determine if the new state is a safe state  Look for an acceptable row (process) with unmet resource needs smaller than or equal to available resources.  If no such row exists the system may eventually deadlock since no process can be guaranteed to run to completion  If such a row exists assume that the process corresponding to the row L requests all its needed resources an runs to completion. Then mark process L as completed and add the resources it released to the A vector  Repeat until all processes (rows) complete (safe state) or until no acceptable row is found (unsafe state).

© Janice Regan, CMPT 300, May  Check row L=1  (R-C) L = [2, 2, 2, 1] (R-C) L > A An example: is new state safe

© Janice Regan, CMPT 300, May  Check row L=2  (R-C) L = [0, 0, 1, 0] (R-C) L <= A  Allocate resources and run process 2 to completion  Reallocate resources from process 2 to available (A)  Mark process 2 as terminated An example: is new state safe

© Janice Regan, CMPT 300, May  Check row L=1  (R-C) L = [2, 2, 2, 1] (R-C) L <= A  Allocate resources and run process 1 to completion  Reallocate resources from process 1 to available  Mark process 1 as terminated An example: is new state safe Row (process marked as completed)

© Janice Regan, CMPT 300, May  Check row L=3  (R-C) L = [1, 0, 3, 0] (R-C) L <= A  Allocate resources and run process 3 to completion  Reallocate resources from process 3 to available  Mark process 3 as terminated An example: is new state safe

© Janice Regan, CMPT 300, May  Check row L=4  (R-C) L = [4, 2, 0, 1] (R-C) L <= A  Allocate resources and run process 4 to completion  Reallocate resources from process 4 to available  Mark process 4 as terminated An example: is new state safe

© Janice Regan, CMPT 300, May  Check row L=4  All process are marked as terminated  Therefore, this is a safe state  Allow the resources to be allocated and proceed with execution of all processes An example: is new state safe

© Janice Regan, CMPT 300, May New starting state: next request

© Janice Regan, CMPT 300, May Next Request to check for safety  Now start from this safe state and consider the next request for resources  Process 1 is now requesting 1 more of resource of resource 3  Do we grant this request? Might this request cause deadlock?  Step 1: Calculate the state of the system if this request is filled  Step 2: determine if the new state is a safe state, use the bankers algorithm

© Janice Regan, CMPT 300, May  Check row L=1, L=2, L=3  (R-C) 1 = [2, 2, 1, 1] (R-C) 1 > A  (R-C) 2 = [0, 0, 1, 0] (R-C) 2 > A  (R-C) 3 = [1, 0, 3, 0] (R-C) 3 > A  (R-C) 4 = [4, 2, 1, 0] (R-C) 4 > A New starting state: next request Is this state safe? UNSAFE!!!, no row marked as complete! All processes may be deadlocked

© Janice Regan, CMPT 300, May Unsafe state vs. deadlock  The unsafe state indicates not that the system is deadlocked or will become deadlocked but that there is potential for deadlock if the system operates in that state  Thus, to avoid deadlock we do not allow the system to allocate resources that would put it into an unsafe state.  This is a conservative strategy. It is possible that processes blocked because of a risk of deadlock would not in fact have caused a deadlock  We are basing our ‘detection’ of a deadlock on worst case assumptions  The process may use all the resources it needs at any time

© Janice Regan, CMPT 300, May  Check row L=1, L=2, L=3  (R-C) 1 = [5, 2, 2, 0] (R-C) 1 > A  (R-C) 2 = [5, 3, 3, 2] (R-C) 2 > A  (R-C) 3 = [0, 0, 0, 2] (R-C) 3 <= A A different system Is this state safe? 2 2

© Janice Regan, CMPT 300, May  Check row L=1, L=2, L=3  (R-C) 1 = [5, 2, 2, 0] (R-C) 1 > A  (R-C) 2 = [5, 3, 3, 2] (R-C) 2 > A  (R-C) 4 = [6, 3, 0, 4] (R-C) 4 > A A different system Is this state safe? UNSAFE!!!, no more rows marked as complete! All 3 remaining processes may be deadlocked 42

© Janice Regan, CMPT 300, May Deadlock  Deadlock avoidance: Each time a resource is requested  determine the state of the system after the resource is allocated, and if that state is safe or unsafe (will potentially deadlock).  If the state will be unsafe we block the process and do not allocate the requested resources (avoid the potential deadlock)  Deadlock prevention:  Make sure one of the conditions that are necessary to create a deadlock cannot be present in the system  Deadlock detection:  Let deadlock happen  Monitor the system state periodically to detect when deadlock occurs  take action to break the deadlock

© Janice Regan, CMPT 300, May Recognizing Deadlock  To implement deadlock avoidance we must be able to recognize when the proposed state (state after allocation of the requested resource) is safe or unsafe  The banker’s algorithm was used to determine if the potential state was safe or unsafe  To implement deadlock detection we can use the same algorithm  Periodically use the bankers algorithm to analyze the state of the system  If the state is unsafe take actions to break actual or potential deadlocks and bring the system back to a safe state

© Janice Regan, CMPT 300, May Detecting deadlock  When should the system be checked for deadlock.  Deadlock avoidance requires checking each time an allocation of resources is made. The same might be done for deadlock detection. This can be expensive.  The state of the system can be periodically checked. A longer period between checks gives  Higher efficiency due to less calculation involved in the checking  Possible lower efficiency because as yet undetected deadlocks can persist for longer times  Periodic checking requires a more complicated OS than checking at each resource allocation

© Janice Regan, CMPT 300, May When a deadlock is detected  When a periodic system check is done  The state of the system is determined  The banker’s algorithm is run  Then either System is in a safe state: no deadlock System is in an unsafe safe state: unmarked processes may be deadlocked  Problem processes have been identified, what should be done next?

© Janice Regan, CMPT 300, May Recovery from deadlock: 1  Abort all deadlocked processes:  most common solution implemented in OSs  Rollback:  Back up each process periodically  in the case of deadlock roll back to the previous backup (checkpoint).  It is possible the deadlock may reoccur.  Usually the backlog will not reoccur because the nondeterministic nature of the execution of concurrent processes

© Janice Regan, CMPT 300, May Recovery from deadlock: 2  Successively abort deadlocked processes.  Abort 1 deadlocked process at at time  Then check if the deadlock still occurs If it does abort the next process If it does not, continue execution of the remaining processes without aborting any more processes  Successively preempt resources from blocked jobs  Preempt 1 deadlocked resource in 1 process  Roll back that process to the point where the preempted resource was allocated  Check if deadlock still occurs If it does preempt resource from the next process If it does not, continue execution of the remaining processes without preempting any more resources

© Janice Regan, CMPT 300, May Choosing processes/resources  For options 3 and 4 it is necessary to choose which of the possibly deadlocked processes to abort or which resource to preempt (and the possibly deadlocked process to preempt it from)  Can base this decision on a number of different criteria  Lowest priority  Most estimated run time remaining  Least number of total resources allocated  Smallest amount of CPU consumed so for

© Janice Regan, CMPT 300, May Issues  None of these approaches is appropriate for all types of resources  Some processes (like updating a data base) cannot be killed and rerun safely  Some resources cannot be safely preempted (some of these like printers can be preempted if spooling is used)  Some processes cannot be rolled back How do you roll back shared variables that have been successively updated by multiple processes  Process rollback is expensive Successive checkpoints must save both image and state Multiple checkpoints need to be saved for a process