Deadlock Chapter 3

1. DeadlockChapter 3 R1 P1 P2 R2 Allocated Requested

2. Resources • Processes compete for system resources • CPU cycles • I/O devices • Printers • Tape drives • Files • Tables • Database records

3. Resources: Preemptible vs. Nonpreemptible • Preemptible • Can be taken away from a process without ill effect • Examples? • Nonpreemptible • Taking it away from a process causes the process to fail • We are concerned with nonpreemptable resources

4. How a process relates to a (nonpreemptible) resource • It requests the resource • What can it do if it isn’t available? • It uses the resource • It releases the resource, making it available to another process

5. Using a semaphore to protect resources One resource Two resources

6. Using semaphores to protect resources Deadlock-free Deadlock-prone

7. The problem of deadlock • If a process is waiting for a resource that is held by another process that is waiting for another resource held by another process… • A set of processes is in a deadlocked state when every process is waiting for an event that can be caused only by another process in the set

8. The four necessary conditions for deadlock to occur • Mutual exclusion • the resource can be used by only one process at a time • Hold & wait or resource holding • processes are permitted to hold onto their current resources while they wait for others • No preemption • no process can bump another for its resource • Circular wait • can show that there is a cycle

9. Resource allocation graphs for deadlock modeling a) Resource R is assigned to Process A b) Process B is waiting for Resource S c) Processes C & D are in deadlock over Resources T & U

10. Creating deadlock A B C

11. Avoiding deadlock

12. Addressing the issue of deadlock • Ignorance • Ostrich algorithm • Detection & recovery • Scan the system looking for cycles of hold & wait • Implement recovery algorithms • Avoidance • If it seems that deadlock is a possibility, do something to keep it from happening • Prevention • negate one of the four necessary conditions

13. Ignorance: Ostrich Algorithm • Pretend there is no problem • Reasonable if • deadlocks occur very rarely • cost of prevention is high • UNIX and Windows takes this approach • It is a trade off between • convenience • correctness

14. Deadlock detection in a graph • Find a process not waiting for any resource. • Remove its allocation arrows & reallocate its resources • Find a process that is waiting only for resources that are not completely allocated. • Remove these allocation arrows & reallocate the resources • Repeat until all lines have been removed or you determine that they cannot all be removed.

15. Resource graph: detection with one resource of each type A cycle can be found within the graph, denoting deadlock T

16. Resource graph: detection with multiple resources of each type R1 R3 P1 P2 P3 R2 R4

17. Data structures needed for detection with multiple resources of each type n Σ Cij + Aj = Ej i=1 Fig. 3-6

18. Detection with multiple resources of each type Resources in existence Resources available See pp. 172-173

19. Recovery from deadlock • Recovery through preemption • take a resource from some other process • depends on nature of the resource • Recovery through rollback • checkpoint a process periodically • use this saved state • restart the process if it is found deadlocked

20. Recovery from deadlock • Recovery through killing processes • crudest but simplest way to break a deadlock • kill one of the processes in the deadlock cycle • the other processes get its resources • choose process that can be rerun from the beginning

21. Avoidance – Banker’s algorithm • Use an algorithm similar to what a bank uses to ensure that it always has funds on hand to satisfy its customers’ eventual needs • Each process must state upfront what its maximum resource needs will be • Deal with safe and unsafe states • avoid unsafe states • Working with multiple instances of resources

22. Safe state We have a total of 10 instances of a given resource, with processes A, B, C holding & eventually needing what is indicated here: State (a) is safe because • It is not deadlocked • There is a scheduling order for each process to run to completion (a) (b) (c) (d) (e)

23. Unsafe states State (b) is unsafe because • There is no way to satisfy all processes after it (a) (b) (c) (d)

24. Banker's Algorithm for multiple instances of a single resource Are each of these states safe or unsafe? (a) (b) (c)

25. Banker's Algorithm for multiple resources

26. Prevention • Don’t allow mutual exclusion • Eliminate resource holding • Allow preemption • Modify circular wait

27. Preventing the “mutual exclusion” condition • Devices, such as printer, can be spooled • only the printer daemon uses printer resource • thus deadlock for printer eliminated • But not all devices can be spooled, so abide by the principle: • Allow as few processes as possible to actually claim the resource

28. Preventing the “hold and wait” condition • Require processes to request all resources before starting • Then, a process never has to wait for what it needs • Problems • Process may not know required resources at start • Ties up resources other processes could be using

29. Preventing the “no preemption” condition • This is not usually a viable option • Consider a process given the printer • halfway through its job • now forcibly take away printer • !!??

30. Preventing the “circular wait” condition Allocate in order Order resources

31. Summary of approaches to deadlock prevention

32. Related issues • Two-phase locking in databases • Deadlocking on semaphores • Starvation in CPU scheduling