1. Deadlocks Vivek Pai / Kai Li Princeton University

2. 2 Bankgedanken How much money do banks keep? What is a bank run? How do you handle it?

3. 3 Mechanics Dec 10 class canceled Readings – sketchy from here on Next project – VM Wednesday night midterm discussion 8:30pm, room 105 Rough “grades” will be sent out soon

4. 4 Let’s Talk About Deadlocks wish I’d read Chapter 3

5. 5 Definitions Resources Preemptable (can be taken away): CPU Non-preemptable (cannot be taken away): Disk, files, mutex,... Starvation Processes/threads wait indefinitely Typical way to use a resource Request Use Release

6. 6 Resource Allocation Graph Process A is holding resource R Process B requests resource S A cycle in the resource allocation graph means that there is deadlock If A requests for S while holding R, and B requests for R while holding S, then AR BS AS BR

7. 7 An Example A utility program copies a file from a tape to disk prints the file to a printer Resources tape disk printer A deadlock tapediskprinter A B

8. 8 What Causes Deadlocks? Guns don’t cause deadlocks – people do

9. 9 Conditions for Deadlock Mutual exclusion condition Each resource is assigned to exactly one process Hold and Wait Multiple independent requests No preemption Resources cannot be taken away Circular chain of requests Note: eliminating any condition eliminates deadlock

10. 10 Eliminate Competition for Resources? If running A to completion and then running B, there will be no deadlock Generalize this idea for all processes? Is it a good idea to develop a CPU scheduling algorithm that causes no deadlock? AS BR Previous example

11. 11 Strategies Ignore the problem It is user’s fault Detection and recovery Fix the problem afterwards Dynamic avoidance Careful allocation Prevention Negate one of the four conditions

12. 12 Detection and Recovery Detection Scan resource graph Detect cycles Recovery (difficult) Kill process/threads (can you always do this?) Roll back actions of deadlocked threads What about the tape-disk-printer example?

13. 13 Avoidance Banker’s algorithm for a single resource Each process has a credit Total resources may not satisfy all credits Keep track of resources assigned and needed Check on each allocation whether it is safe Safe: there exists a sequence of other states that all processes can terminate correctly Multiple resources Read textbook for details

14. 14 Practical Avoidance Two-phase locking Phase I: Try to lock all resources at the beginning Phase II: If successful, use the resources & release them If not, release all resources and start over What about the tape-disk-printer example?

15. 15 Prevention: Remove Mutual Exclusion Some resources are not sharable Printer, tape, etc Some resources can be made sharable Read-only files, memory, etc Read/write locks Some resources can be made virtual Spooling Does spooling apply to all non-sharable resources? What about the tape-disk-printer example?

16. 16 Prevention: Remove Hold and Wait Method Request for all resources before starting execution If all available, it would run Otherwise, it will wait This is how telephone company prevents deadlocks Problems with this approach? What about the tape-disk-printer example?

17. 17 Prevention: No Preemption Make scheduler aware of resource allocation Method If a request from a process holding resources cannot be satisfied, preempt the process and release all resources Schedule it only if the system satisfies all resources Alternative Preempt the process holding the requested resource Copying Copying to a buffer to release the resource? What about the tape-disk-printer example?

18. 18 Prevention: No Circular Wait Impose an order of requests for all resources Method Assign a unique id to each resource All resource requests must be in an ascending order of the ids Release resources in a descending order Can you prove this method has no circular wait? Does this method work for the tape-disk- printer example?

19. 19 Why Do We Care About This? Two possibilities Bitten all the time by this Strive to never have it Why? Fact of life for some applications Faulty programming in others

20. 20 Parallel Scientific Applications Really expensive machines Overhead counts Parallel programs, shared data Assumption of smart programmers Deadlock detection support is wasted Correct programs don’t use it Incorrect programs don’t survive

21. 21 Data Access in Scientific Apps Lots of small accesses Locks often released quickly Structured data Directed acyclic graphs, trees, etc Predictable patterns of access Result: deadlock avoidance schemes

22. 22 Databases: Insanely Profitable Large amount of shared data Lots of accesses to it Uncoordinated accesses Often no predictability Data-dependent program flow End-users had different concerns Result: good deadlock mechanisms needed

23. 23 Concept of Transactions Simplified description Preserves invariants All-or-nothing behavior Start/end declared No permanent modifications until end Restart capabilities assumed