1. Deadlock, Illustrated

2. Deadlock
CSE451
Andrew Whitaker
TODO: print handouts for AspectRatio

3. 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

4. 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

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

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

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

8. 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

9. 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

10. 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

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

12. 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

13. 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

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

15. 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

16. 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

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

18. 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

19. 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