Deadlock CSE451 Andrew Whitaker

Review: What Can Go Wrong With Threads? Safety hazards  “Program does the wrong thing” Liveness hazards  “Program never does the right thing” Performance hazards  Program is too slow due to excessive synchronization

A Liveness Hazard: Starvation A thread is ready, but the scheduler does not select it to run  Can be caused by shortest-job-first scheduling

Deadlock Each thread is waiting on a resource held by another thread  So, there is no way to make progress Thread 1 Thread 2Thread 3

Deadlock, Illustrated

Necessary Conditions for Deadlock Mutual exclusion  Resources cannot be shared e.g., buffers, locks Hold and wait (subset property)  A thread must hold a subset of its resource needs And, the thread is waiting for more resources No preemption  Resources cannot be taken away Circular wait  A needs a resource that B has  B has a resource that A has

Resource Allocation Graph with a Deadlock Silberschatz, Galvin and Gagne  2002 P => R: request edge R => P: assignment edge

Cycle Without Deadlock P => R: request edge R => P: assignment edge Silberschatz, Galvin and Gagne  2002 Why is there no deadlock here?

Graph Reduction A graph can be reduced by a thread if all of that thread’s requests can be granted  Eventually, all resources by the reduced thread will be freed Miscellaneous theorems (Holt, Havender):  There are no deadlocked threads iff the graph is completely reducible  The order of reductions is irrelevant (Detail: resources with multiple units)

Approaches to Deadlock 1.Avoid threads 2.Deadlock prevention  Break up one of the four necessary conditions 3.Deadlock avoidance  Stay live even in the presence of the four conditions 4.Detect and recover

Approach #1: Avoid Threads Brain dead solution: avoid deadlock by avoiding threads Example: GUI frameworks  Typically use a single event-dispatch thread Operating System GUI Framework Application mouse click change background color

Approach #2: Prevention Can we eliminate: Mutual exclusion? Hold and wait (subset property)? No Preemption? Circular waiting?

Lock Ordering We can avoid circular waiting by acquiring resources in a fixed order Example: Linux rename operation  Each open file has a semaphore  Both semaphores must be held during file operations  Linux always uses the same order for down operations Semaphore at the lowest memory address goes first

Rename Example Process 1: rename (“foo.txt”,”bar.txt”); Process 2: rename (“bar.txt”,”foo.txt”); down() foo semaphore down() bar semaphore up() bar semaphore up() foo semaphore down() foo semaphore down() bar semaphore up() bar semaphore up() foo semaphore

Approach #3: Avoidance Intuition: the four conditions do not always lead to deadlock  “necessary but not sufficient” We can stay live if we know the resource needs of the processes

Bankers Algorithm Overview Basic idea: ensure that we always have an “escape route”  The resource graph is reducible This can be enforced with the bankers algorithm:  When a request is made Pretend you granted it Pretend all other legal requests were made  Can the graph be reduced? If so, allocate the requested resource If not, block the thread

Deadlock Avoidance in Practice Static provisioning  Ensure that each active process/thread can acquire some minimum set of resources  Use admission control to maintain this invariant This is closely related to the idea of thrashing  Each thread needs some minimum amount of resources to run efficiently

Approach #4: Detection and Recovery Not commonly used  Detection is expensive  Recovery is tricky Possible exception: databases

Deadlock Detection Detection algorithm (sketch)  Keep track of who is waiting for resources  Keep track of who holds resources  Assume that all runnable processes release all their resources Does this unblock a waiting process? If yes, release that process’s resources  If processes are still blocked, we are deadlocked

Recovery Must “back out” of a resource allocation decision  By preemption or by killing the process This is particularly problematic for lock- based deadlocks  System can be in an inconsistent state