1. CS 346 – Chapter 7 Deadlock –Properties –Analysis: directed graph Handle –Prevent –Avoid Safe states and the Banker’s algorithm –Detect –Recover

2. Origins of deadlock System contains resources Process compete for resources: –request, acquire / use, release Deadlock occurs on a set of processes when each one is waiting for some event (e.g. the release of a resource) that can only be triggered by another deadlocked process. –e.g. P1 possesses the keyboard, and P2 has the printer. P1 requests the printer and goes to sleep waiting. P2 requests the keyboard and goes to sleep waiting. –Sometimes hard to detect because it may depend on the order in which resources are requested/allocated

3. Necessary conditions 4 conditions to detect for deadlock: Mutual exclusion – when a resource is held, the process has exclusive access to it Hold and wait – processes each hold 1+ resource while seeking more No preemption – a process will not release a resource unless it’s finished using it Circular wait The first 3 conditions are routine, so it’s the circular wait that is usually the big problem. –Model using a directed graph, and look for cycle

4. Directed graph A resource allocation graph is a formal way to show we have deadlock Vertices include processes and resources Directed edges –(P  R) means that process requests a resource –(R  P) means that resource is allocated to process If a resource has multiple instances –Multiple processes may request or be allocated the resource –Intuitive, but make sure you don’t over-allocate –e.g. Figure 7.2: Resource R2 has 2 instances which are both allocated. But process P3 also wants some of R2. The “out” degree of R2 is 2 and “in” degree is 1.

5. Examples R2 has 2 instances. –We can have these edges: P1  R2, P2  R2, P3  R2. –What does this situation mean? What should happen next? Suppose R1 and R2 have 1 instance each. –Edges: R1  P1, R2  P2, P1  R2 –Describe this situation. –Now, add this edge: P2  R1 –Deadlock? Fortunately, not all cycles imply a deadlock. –There may be sufficient instances to honor request –Fig 7.3 shows a cycle. P1 waits for R1 and P3 waits for R2. But either of these 2 resources can be released by processes that are not in the cycle…. as long as they don’t run forever.

6. How OS handles Ostrich method – pretend it will never happen. Ignore the issue. Let the programmer worry about it. –Good idea if deadlock is rare. Dynamically prevent deadlock from ever occurring –Allow up to 3 of the 4 necessary conditions to occur. –Prevent certain requests from being made. A priori avoidance –Require advance warning about requests, so that deadlock can be avoided. –Some requests are delayed Detection –Allow conditions that create deadlock, and deal with it as it occurs. –Must be able to detect!

7. Prevention “An ounce of prevention is worth a pound of cure”: Benjamin Franklin Take a look at each of the 4 necessary conditions. Don’t allow it to be the 4 th nail in the coffin. 1.Mutual exclusion –Not much we can do here. Some resources must be exclusive. –Which resources are sharable? 2.Hold & wait –Could require a process to make all its requests at the beginning of its execution. –How does this help? –Resource utilization; and starvation?

8. Prevention (2) 3. No resource preemption –Well, we do want to allow some preemption –If you make a resource request that can’t be fulfilled at the moment, OS can require you to release everything you have. (release = preempting the resource) –If you make a resource request, and its held by a sleeping process, OS can let you steal it for a while. 4. Circular wait –System ensures the request doesn’t complete a cycle –Total ordering technique: Assign a whole number to each resource. Process must request resources in numerical order, or at least not request a lowered # resource when it holds a higher one. –Fig. 7.2: P3 has resource #3 but also requests #2. OS could reject this request.

9. Avoidance We need a priori information to avoid future deadlock. What information? We could require processes to declare up front the maximum # of resources of each type it will ever need. During execution: let’s define a resource-allocation state, telling us: –# of resources available (static) –Maximum needs of each process (static) –# allocated to each process (dynamic)

10. Safe state To be in a safe state, there must exist a safe sequence. A safe sequence is a list of processes [ P1, P2, … Pn ] –for each P_i, we can satisfy P_i’s requests given whatever resources are currently available or currently held by the processes numbered lower than i (i.e. Pj where j < i) by letting them finish. –For example, all of P2’s possible requests can be met by either what is currently available or by what is held by P1. –If P3 needs a resource held by P2, can wait until P2 done, etc. Safe state =  a safe sequence including all processes. –Deadlock occurs only in an unsafe state. The system needs to examine each request and ensure that if the allocation will preserve the safe state.

11. Example Suppose we have 12 instances of some resource. 3 processes have these a priori known needs We need to find some safe sequence of all 3 processes At present, 12 – (5 + 2 + 2) = 3 instances available. Is [ 1, 2, 3 ] a safe sequence? Process #Max needsCurrent use 1105 242 392

12. Banker’s algorithm General enough to handle multiple instances Principles –No customer can borrow more money than is in the bank –All customers given maximum credit limit at outset –Can’t go over your limit! –Sum of all loans never exceeds bank’s capital. Good news: customers’ aggregate credit limit may be higher than bank’s assets Safe state: Bank has enough “money” to service request of 1 customer. Algorithm: satisfy a request only if you stay safe –Identify which job has smallest remaining requests, and make sure we always have enough dough

13. Example Consider 10 devices of the same type Processes 1-3 need up to 4, 5, 8 of these devices, respectively Are these states safe? Job# allocatedMax needed 104 225 348 Job# allocatedMax needed 124 235 348

14. Handling deadlock Continually employ a detection algorithm –Search for cycle –Can do it occasionally When deadlock detected, perform recovery Recover by killing –Kill 1 process at a time until deadlock cycle gone –Kill which process? Consider: priority, how many resources it has, how close it is to completion. Recover by resource preemption –Need to restart that job in near future. –Possibility for starvation if the same process is selected over and over.

15. Detection algorithm Start with allocation graph, and “reduce it” While no changes do: Find a process using a resource & not waiting for one. Remove edge: process will eventually finish. Can now re-allocate this resource to another process, if needed. Also can perform other resource allocations for resources not fully allocated. If there are any edges left, we have deadlock.

16. Example 3 processes & 3 resources Edges: –(R1  P1) –(P1  R2) –(R2  P2) –(P2  R3) –(R3  P3) Can this graph be reduced to the point that it has no edges?