1 / 20

Deadlock

This review discusses the potential issues that can arise with threads, including safety hazards, liveness hazards, and performance hazards. It also covers the concept of deadlock, its necessary conditions, and approaches to handle it such as avoidance and detection. The text provides examples and explanations to enhance understanding.

bettymarshall
Télécharger la présentation

Deadlock

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Deadlock CSE451 Andrew Whitaker

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

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

  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. Deadlock, Illustrated

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related