Copyright ©: Nahrstedt, Angrave, Abdelzaher1 Deadlock

Copyright ©: Nahrstedt, Angrave, Abdelzaher 2 Deadlock

Copyright ©: Nahrstedt, Angrave, Abdelzaher 3 Deadlock Definition What is Deadlock? Two or more processes are deadlocked if each process is waiting on one of the others to proceed Typically, each process holds one resource and is waiting on a resource some other deadlocked process holds What is starvation? A process is starved if it may logically proceed but is overlooked (not given resources) indefinitely by a scheduling or allocation policy Usually, other processes are able to proceed

Copyright ©: Nahrstedt, Angrave, Abdelzaher 4 Requirements for Deadlock What are they?

Copyright ©: Nahrstedt, Angrave, Abdelzaher 5 Requirements for Deadlock Necessary (not sufficient) conditions Mutual exclusion Processes claim exclusive control of the resources they require Hold-and-wait (a.k.a. wait-for) condition Processes hold resources already allocated to them while waiting for additional resources No preemption condition Resources cannot be removed from the processes holding them until used to completion These may lead to deadlock.

Copyright ©: Nahrstedt, Angrave, Abdelzaher 6 Requirements for Deadlock Necessary and sufficient conditions … Mutual exclusion Processes claim exclusive control of the resources they require Hold-and-wait (a.k.a. wait-for) condition Processes hold resources already allocated to them while waiting for additional resources No preemption condition Resources cannot be removed from the processes holding them until used to completion Circular wait condition: deadlock has occurred A circular chain of processes exists in which each process holds one or more resources that are requested by the next process in the chain

Copyright ©: Nahrstedt, Angrave, Abdelzaher 7 Requirements for Deadlock (Dining Philosophers Example) Mutual exclusion Exclusive use of chopsticks Hold and wait condition Hold 1 chopstick, wait for next No preemption condition Cannot force another to drop a chopstick Circular wait condition Each waits for next neighbor to release chopstick

Copyright ©: Nahrstedt, Angrave, Abdelzaher 8 Mutual Exclusion Processes claim exclusive control of the resources they require How to break it?

Copyright ©: Nahrstedt, Angrave, Abdelzaher 9 Wait-for Condition Processes hold resources already allocated to them while waiting for additional resources How to break it?

Copyright ©: Nahrstedt, Angrave, Abdelzaher 10 No Preemption Condition Resources cannot be removed from the processes holding them until used to completion How to break it?

Copyright ©: Nahrstedt, Angrave, Abdelzaher 11 Circular Wait Condition A circular chain of processes exists in which each process holds one or more resources that are requested by the next process in the chain How to break it?

Copyright ©: Nahrstedt, Angrave, Abdelzaher 12 Resource Allocation Graph Nodes Processes Resources Arcs From resource to process = resource assigned to process From process to resource = process requests resource

Copyright ©: Nahrstedt, Angrave, Abdelzaher 13 resource R assigned to process A process B requests, then waits for resource S process C, D are deadlocked for resources T, U assign request Resource Allocation Graph

Copyright ©: Nahrstedt, Angrave, Abdelzaher 14 Strategies Strategies for dealing with Deadlocks detection and recovery dynamic avoidance (at run-time) prevention (by off-line design) negating one of the four necessary conditions

Copyright ©: Nahrstedt, Angrave, Abdelzaher 15 Deadlock Issues Prevention design a system in such a way that deadlocks cannot occur, at least with respect to serially reusable resources. Avoidance impose less stringent conditions than for prevention, allowing the possibility of deadlock, but sidestepping it as it approaches. Detection and Recovery in a system that allows the possibility of deadlock, determine if deadlock has occurred, and which processes and resources are involved. after a deadlock has been detected, clear the problem, allowing the deadlocked processes to complete and the resources to be reused. Usually involves destroying the affected processes and starting them over.

Copyright ©: Nahrstedt, Angrave, Abdelzaher 16 The Default Solution Don’t do anything normally (“ostrich” approach!) detect cheaply: progress timer recover “simply”: restart the system Rationale: make the common path faster and more reliable deadlock prevention, avoidance or detection/recovery algorithms are expensive if deadlock occurs only rarely, it is not worth the overhead to implement any of these algorithms.

Copyright ©: Nahrstedt, Angrave, Abdelzaher 17 Deadlock Prevention Break one of the deadlock conditions. Mutual exclusion Solution: Usually none except to eliminate concurrency (e.g., spooling) Hold-and-Wait condition Solution: Force each process to request all required resources at once. It cannot proceed until all resources have been acquired. Two-phase locking No preemption condition Solution: Allow a process to be aborted by another when competing over a resource Circular wait condition Solution: All resource types are numbered. Processes must request resources in numerical order

Copyright ©: Nahrstedt, Angrave, Abdelzaher 18 Deadlock Avoidance Avoidance: impose less stringent conditions than for prevention, allowing the possibility of deadlock but sidestepping it as it approaches Banker algorithm Each process specifies the maximum number of resources it needs of each type For each request, the system checks if granting this request may lead to a deadlock in the worse case If yes, do not grant the request If no, grant the request

Copyright ©: Nahrstedt, Angrave, Abdelzaher 19 Deadlock Avoidance Banker Algorithm (Dijkstra, 1965) Each customer tells banker the maximum number of resources it needs Customer borrows resources from banker Customer returns resources to banker Customer eventually pays back loan Banker only lends resources if the system will be in a safe state after the loan Safe state - there is a lending sequence such that all customers can take out a loan Unsafe state - there is a possibility of deadlock

Copyright ©: Nahrstedt, Angrave, Abdelzaher 20 Safe State and Unsafe State Safe State there is some scheduling order in which every process can run to completion even if all of them request their maximum number of resources immediately From safe state, the system can guarantee that all processes will finish Unsafe state: no such guarantee Not deadlocked state Some process may be able to complete

Copyright ©: Nahrstedt, Angrave, Abdelzaher 21 Is Allocation (1 0 2) to P1 Safe? If P1 requests max resources, can complete

Copyright ©: Nahrstedt, Angrave, Abdelzaher 22 Run Safety Test If P1 requests max resources, can complete

Copyright ©: Nahrstedt, Angrave, Abdelzaher 23 Allocate to P1, Then

Copyright ©: Nahrstedt, Angrave, Abdelzaher 24 Release - P1 Finishes Now P3 can acquire max resources and release

Copyright ©: Nahrstedt, Angrave, Abdelzaher 25 Release - P3 Finishes Now P4 can acquire max resources and release

Copyright ©: Nahrstedt, Angrave, Abdelzaher 26 Release - P4 Finishes Now P2 can acquire max resources and release

Copyright ©: Nahrstedt, Angrave, Abdelzaher 27 Release - P2 Finishes Now P0 can acquire max resources and release

Copyright ©: Nahrstedt, Angrave, Abdelzaher 28 So P1 Allocation (1 0 2) Is Safe

Copyright ©: Nahrstedt, Angrave, Abdelzaher 29 Is allocation (0 2 0) to P0 Safe? Try to Allocate 2 B to P0

Copyright ©: Nahrstedt, Angrave, Abdelzaher 30 Run Safety Test No Processes may get max resources and release

Copyright ©: Nahrstedt, Angrave, Abdelzaher 31 So Unsafe State- Do Not Enter Return to Safe State and do not allocate resource

Copyright ©: Nahrstedt, Angrave, Abdelzaher 32 P0 Suspended Pending Request When enough resources become available, P0 can awake

Copyright ©: Nahrstedt, Angrave, Abdelzaher 33 Deadlock Detection Check to see if a deadlock has occurred! Single resource per type Can use wait-for graph Check for cycles How?

Copyright ©: Nahrstedt, Angrave, Abdelzaher 34 Wait for Graphs Resource Allocation GraphCorresponding Wait For Graph

Copyright ©: Nahrstedt, Angrave, Abdelzaher 35 Recovery From Deadlock OPTIONS: Kill deadlocked processes, release resources Kill one deadlocked process at a time and release its resources Rollback all or one of the processes to a checkpoint that occurred before they requested any resources Note: with rollback, difficult to prevent indefinite postponement

Copyright ©: Nahrstedt, Angrave, Abdelzaher 36 Notes In general, deadlock detection or avoidance is expensive Must evaluate cost of deadlock against detection or avoidance costs Deadlock avoidance and recovery may cause indefinite postponement Unix and Windows use the Ostrich Algorithm (do nothing)