Deadlock, Illustrated

Deadlock CSE451 Andrew Whitaker TODO: print handouts for AspectRatio

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

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

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 Buffer pool: Buffers cannot be shared Each thread can allocate some (but not all) of its resource No way for resources to be taken away Thread A needs the buffers of thread B (and vice versa)

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

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

Theory: 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

Approaches to Deadlock Avoid threads Deadlock prevention Break up one of the four necessary conditions Deadlock avoidance Stay live even in the presence of the four conditions 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”); foo lock bar lock bar lock foo lock acquire acquire release release foo lock bar lock bar lock foo lock acquire acquire release release

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