Deadlock

1. Deadlock • B.Ramamurthy CSE421 B.Ramamurthy

2. Introduction • Parallel operation among many devices driven by concurrent processes contribute significantly to high performance. But concurrency also results in contention for resources and possibility of deadlock among the vying processes. • Deadlock is a situation where a group of processes are permanently blocked waiting for the resources held by each other in the group. • Typical application where deadlock is a serious problem: Operating system, data base accesses, and distributed processing. B.Ramamurthy

3. Topics for discussion • Types of resources • Conditions for deadlock • Deadlock prevention • Deadlock detection • Deadlock avoidance • Dining philosophers problem B.Ramamurthy

4. Types of resources • Two general categories of resources: reusable and consumable. • Reusable resource: One that can be safely used by one process at a time and not depleted by the use. Later it can be used by some other process. Examples: processors, IOU channels, main and secondary memory, devices, files, databases, semaphores, locks. • Consumable resource: One that can be produced and consumed (destroyed). Examples: interrupts, signals, messages, information in IO buffers. B.Ramamurthy

5. Conditions for a deadlock • Four preconditions that must be present for a deadlock to occur: • Mutual exclusion: Only one process can use a resource at a time. • Hold and wait: A process must hold the resources while awaiting assignment of other resources. • No preemption: No resource can be forcibly removed from a process holding it. • Circular wait: A closed chain of processes exists, such that each process holds at least one resources needed by the next process in the chain. B.Ramamurthy

6. General design policy • What is your policy? • Spend resources, effort and time during normal operation to prevent deadlock from occurring ? (pessimistic and conservative) or • Incur low overhead during normal deadlock-free operation without worrying about deadlock. Take care of resolving it when and if it happens? (optimistic). In this case, recovery from deadlock may be expensive. • Detect deadlock and recover. • Optimal solution? between cost of recovery and cost of prevention. B.Ramamurthy

7. Deadlock prevention • To design a system in such a way that the possibility of a deadlock is excluded a priori. • Prevention philosophy: We know what the preconditions are; So prevent one or more these from occurring. • For example: Circular wait can be prevented by linear ordering of the resource types. If a process holds resources of type Rj , then it can request resources of type Rk, k > j, but not Ri where i <= j. Similarly, any other process holding Ri can request Rj but a process holding Rj cannot request Ri. B.Ramamurthy

8. Deadlock detection • All the resource requests by processes are granted as long as they within the availability limits. Periodically the OS checks for circular wait and resolves it. • Policy1: When to check for circular wait? Every time a resource request is made? For every “n-th” request? • Policy2: How to break the deadlock once detected? • Question: What is a policy ? and What is a mechanism? Ans: “WHAT to do” and “HOW to do” describe policy and mechanism respectively. B.Ramamurthy

9. How to break a deadlock? Soln1: Abort all deadlocked processes and reclaim resources. Soln2: Back up all the deadlock processes to a predefined checkpoint and restart. Soln3: Gradually abort processes in deadlock one by one until deadlock is resolved. Soln4: Successively preempt resources until deadlock is cleared. B.Ramamurthy

10. Scope of various policies • Total deadlock prevention leads to inefficient use of resources and inefficient execution of processes. DETECTION Definite deadlock UNSAFE Deadlock possible but no deadlock AVOIDANCE SAFE No Deadlock possible PREVENTION B.Ramamurthy

11. Deadlock avoidance • Deadlock avoidance requires some future knowledge of requests for resources from each of the participating processes. • Policies for avoidance: (what to do?) • Do not start a process if its demands might lead to a deadlock. • Do not grant an incremental resource request to a process if this allocation might lead to a deadlock. B.Ramamurthy

12. Deadlock avoidance mechanism • (How to do it?) • Data structures • Algorithms : • Resource allocation algorithm • Testing for safety algorithm (Banker’s algorithm) • Assume n processes, m different types of resources. B.Ramamurthy

13. Deadlock avoidance - Data structures • Data structures: • Resource vector: [R1....Rm] : Total number of resource in the system. Resource[1] is R1, tells that there R1 units of resource type 1. • Available vector : [AV1....AVm] : Currently available. Available[1] is AV1 tells that there are AV1 units of resource 1 available. • Claim matrix : [C1*....Cn*] where each is vector of m elements: Maximum requirement for each process. Claim is a nXm matrix defines the maximum of resources demanded by each process. • Allocation matrix : [A1*...An*] current allocation for each process. It is an nXm matrix . B.Ramamurthy

14. ... avoidance - Resource allocation • If Request[*] > Available[*] suspend process; • else define newstate by: 1) Allocation[i,*] = Allocation[i,*]+ Request[*] 2) Available[*] = Available[*] - Request[*] • If safe (newstate) then go ahead with allocation; • else restore original state and suspend process. B.Ramamurthy

15. Safety algorithm - bool safe(state); • CurrentAvail = Available; • Rest = {set of all processes}; • Possible = True; • while (Possible) && (Rest not Empty) • Find Pk in Rest such that Claim[k,*] - Allocation[k,*] < CurrentAvail; • if found, { CurrentAvail = CurrentAvail + Allocation[k,*]; Rest = Rest - {Pk};} • else Possible = False; • /* ASSERT: either Rest is empty or Allocation failed */ • safe = (Rest is empty); B.Ramamurthy

16. Example : bool safe(state); P1 P2 P3 P4 P1 P2 P3 P4 R1 3 6 3 4 1 6 2 0 R2 2 1 1 2 0 1 1 0 R3 2 3 4 2 0 2 1 2 CLAIM MATRIX ALLOCATION MATRIX R1 2 0 1 4 R2 2 0 0 2 R3 2 1 3 0 NEED MATRIX = CLAIM --- ALLOCATION B.Ramamurthy

17. Example (contd.) • With the state of the system as given above and the current availability as given by AVAIL [R1 R2 R3 ] = 0 1 1, can you find a sequence of processor execution that will result in a safe state (no deadlock state)? • Some form of serializability. Quite common in data base applications. • Is the given state safe? YES. (means you have safe sequence) • What is the safe sequence? {P2, P1, P3, P4} B.Ramamurthy

18. Example (contd.) • In other words, in the current state P2 can run with AVAIL, P1 can go after completion of P2 with the reclaimed resources from P2+AVAIL, next P3 can go with available resources from {P2,P1}+AVAIL, and finally P4 with resources from {P2,P1,P3}+AVAIL. • Next we will look at an example that illustrates complete allocation scheme “avoids” deadlock by making use of this safety algorithm discussed above. B.Ramamurthy

19. Current state - AVAIL [1 1 2] P1 P2 P3 P4 P1 P2 P3 P4 R1 3 6 3 4 1 5 2 0 R2 2 1 1 2 0 1 1 0 R3 2 3 4 2 0 1 1 2 CLAIM MATRIX ALLOCATION MATRIX Request of [1 0 1] by P2 can be safely allocated. Proof: Above example. But the same request from P1 at this state given above is unsafe. So cannot be allocated. B.Ramamurthy

20. Dining philosopher problem • Classic problem is usually discussed with 5 philosophers: But you should really consider N philosophers. • 5 philosophers, 5 plates of noodles, 5 forks and circular dining table. Each one needs two forks. Examine how it satisfies the preconditions for deadlock! • Mutual exclusion : shared fork. • Hold and wait: One may hold the left fork and wait forever for the right fork. • No preemption: One may not want to give up the fork he/she has. • Circular wait: Of course, one waiting on the other around the table. B.Ramamurthy

21. Monitor solution • See the enclosed solution for DP problem using monitors. Can you define a general base class DP that can used to solve any problem that can be modeled as DP? use Posix/Solaris condition variables and mutex for condition and suspension requirements of the monitor. B.Ramamurthy

22. Summary • In general deadlock handling is left to the application level. But this situation may change with proliferation of database and multimedia applications. We need built-in mechanisms. We looked at some of them. • Prevention is conservative, detection and resolution is too optimistic, avoidance attempts to provide a satisfactory solution for some restricted classes of applications. B.Ramamurthy