Deadlock

1. Deadlock

2. Resource Manager Resource Manager Scheduler Resource Manager Process Manager Review Program Process Abstract Computing Environment Process Description File Manager Process Mgr Protection Deadlock Synchronization Device Manager Memory Manager Devices Memory CPU Other H/W

3. Introduction • Let S and Q be two semaphores initialized to 1 P0P1 P(S); P(Q); P(Q); P(S);   V(S); V(Q); V(Q) V(S); • What is the potential problem? • How could we overcome this problem if we want to have least constraints on the programmers?

4. Deadlocks - Introduction • Kansas State legislature • “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other is gone”

5. Bridge Crossing Example • Traffic only in one direction. • Each section of a bridge can be viewed as a resource. • If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback). • Several cars may have to be backed up if a deadlock occurs. • Starvation is possible.

6. Automobile Gridlocks

7. The Deadlock Problem • A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set. • Example • System has 2 tape drives, one CD-ROM and one DAT drive. • P1 and P2 each hold one tape drive and each needs another one.

8. Two-process deadlock

9. Deadlock Examples – cont. • Semaphore example • semaphores A and B, initialized to 1 P0 P1 P(A); P(B); P(B); P(A); • Message deadlock example • Process A { receive(B, msg); send(B, msg): } • Process B { receive(A, msg); send(A, msg): } • Could result from a message being lost

10. Process holds resource Process requests resource Deadlock Examples – cont. Process 1 Process 2 Resource 1 Resource 2

11. Process holds resource Process requests resource Deadlock Examples – cont. Process 1 Process 2 Process 3 Resource 1 Resource 2 Resource 3

12. Deadlock Examples – cont. Application Process Resource Manager Process holds resource Process requests resource Memory Resource Disk Block Resource Deadlock can occur even if one of the processes is executing OS code!

13. Deadlock Characterization • Deadlock can arise if four conditions hold simultaneously • Mutual exclusion • Hold and wait: • No preemption • Circular wait

14. Deadlock Characterization • Mutual exclusion • only one process at a time can use a resource. • Hold and wait: • a process holding at least one resource is waiting to acquire additional resources held by other processes.

15. Deadlock Characterization • No preemption • a resource can be released only voluntarily by the process holding it, after that process has completed its task. • Circular wait • there exists a set {P0, P1, …, Pn} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and Pn is waiting for a resource that is held by P0.

16. A Model • P = {p1, p2, …, pn} be a set of processes • R = {R1, R2, …, Rm} be a set of resources • cj = number of units of Rj in the system • S = {S0, S1, …} be a set of states representing the assignment of Rj to pi • State changes when processes take action • This allows us to identify a deadlock situation in the operating system

17. Resources Resource: Anything that a process can request, then be blocked because that thing is not available. R = {Rj | 0  j < m} = resource types C = {cj 0 |  RjR (0  j < m)} = units of Rj available Reusable resource: After a unit of the resource has been allocated, it must ultimately be released back to the system. E.g., CPU, primary memory, disk space, … The maximum value for cj is the number of units of that resource Consumable resource: There is no need to release a resource after it has been acquired. E.g., a message, input data, … Notice that cj is unbounded.

18. Using the Model • There is a resource manager, Mgr(Rj) for every Rj • Process pi can request units of Rj if it is currently running pi can only request ni cj units of reusable Rj pi can request unbounded # of units of consumable Rj • Mgr(Rj) can allocate units of Rj to pi request Mgr(Rj) Process allocate

19. Resource Manager Blocked Processes Policy Process Process request() Process Process release() Resource Pool A Generic Resource Manager

20. Using the Model – cont. • In most cases, we assume that each process utilizes a resource as follows • request • If the requested resources are not available, the calling process will be blocked • use • release • Which implies that we are dealing with reusable resources

21. State Transitions • The system changes state because of the action of some process, pi • There are three pertinent actions: • Request (“ri”): request one or more units of a resource • Allocation (“ai”): All outstanding requests from a process for a given resource are satisfied • Deallocation (“di”): The process releases units of a resource xi Sj Sk

22. a1 r3 Sj r1 p2 is blocked in Sj Properties of States • Want to define deadlock in terms of patterns of transitions • Define: pi is blocked in Sj if pi cannot cause a transition out of Sj

23. State Diagram • If pi is blocked in Sj, and will also be blocked in every Sk reachable from Sj, then pi is deadlocked • Sj is called a deadlock state

24. State Diagram – simple example d d r a r a S0 S1 S2 S3 S4 • State diagram of one process with one resource of two units • Can request one unit at a time • Progresses from S0 by requesting one unit • Progresses from S1 by acquiring the unit • From S2 can either relinquish the unit or ask for • another unit

25. State Diagram– example • Extend this to two processes competing for two units of the single resource type • Process may request only one unit at a time • State diagram in previous slide must be replicated and copies combined to describe all the system states • Those states not possible have been removed

26. State Diagram – example d0 d0 r0 a0 r0 a0 S00 S10 S20 S30 S40 r1 r1 r1 r1 r1 d0 d0 r0 a0 r0 a0 S01 S11 S21 S31 S41 d1 d1 d1 d1 a1 a1 a1 a1 d0 r0 a0 r0 S02 S12 S22 S32 r1 r1 d0 r1 r1 State S33 is a deadlock state – WHY? r0 a0 r0 S03 S13 S23 S33 d1 d1 a1 a1 r0 S04 S14

27. Dealing with Deadlocks • Three ways • Prevention • place restrictions on resource requests to make deadlock impossible • Avoidance • plan ahead to avoid deadlock. • Recovery • Check for deadlock (periodically or sporadically) and recover from it • Manual intervention (the ad hoc approach) • Reboot the machine if it seems too slow

28. Deadlock Prevention • Necessary conditions for deadlock • Mutual exclusion • Hold and wait • Circular waiting • No preemption • Ensure that at least one of the necessary conditions is false at all times

29. Mutual Exclusion • Not required for sharable resources • MUST hold for nonsharable resources

30. Hold and Wait • Need to be sure a process does not hold one resource while requesting another • Approach 1: Force a process to request all resources it needs at one time • Approach 2: If a process needs to acquire a new resource, it must first release all resources it holds, then reacquire all it needs • What does this say about state transition diagrams?

31. Hold and Wait – cont. - Requesting all resources before starting

32. Hold and Wait – cont. - Release of all resources before requesting more

33. Hold and Wait – cont. • No Preemption – • If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released. • Preempted resources are added to the list of resources for which the process is waiting. • Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting.

34. Hold and Wait– cont. • Results in poor utilization of resources • Can lead to starvation due to resource unavailability

35. Circular Wait • Occurs when a set of n processes that hold units of a set of n different resources • Impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration • Semaphore example • semaphores A and B, initialized to 1 P0 P1 wait (A); wait(A) wait (B); wait(B)

36. Circular Wait • Have a situation in which there are K processes holding units of K resources R P Ri P holds R Pi P R P requests R

37. Circular Wait– cont. • There is a cycle in the graph of processes and resources • Choose a resource request strategy by which no cycle will be introduced • Total order on all resources, then can only ask for Rj if Ri < Rj for all Ri the process is currently holding

38. Circular Wait – cont. • Implementing this strategy • Require that each process requests resources in an increasing order of the associated numbers • A process can request instances of type Ri initially • After that, the process can only request instances of resource type Rj if F(Rj) > F(Ri), where F(Ri) and F(Rj) are the associated integer number • It several instances of the same resource type are needed, all of them must be requested in a single request

39. Circular Wait – cont. • Implementation – continued • Whenever a process requests an instance of resource type Rj, it must first release all the resources Ri, such that F(Ri)  F(Rj) • Circular wait cannot hold if a total ordering is imposed • Can be shown by contradiction

40. Circular Wait – cont. • This is how we noticed an easy solution for the dining philosophers problem • Put a total order on all forks • Require that philosopher 4 become a “left-handed” philosopher (pick up the forks in a different order than the rest)

41. Circular Wait– cont. philosopher(int i) { while (TRUE) { ... /* Thinking */ P(fork[i]); /* Pick up left fork */ P(fork[(i+1) mod 5]; /* Pick up right fork */ eat(); V(fork[(i+1) mod 5]; V(fork[i]); } } philosopher4() { while (TRUE) { ... /* Thinking */ P(fork[0]); /* Pick up right fork */ P(fork[4]; /* Pick up left fork */ eat(); V(fork[4]; V(fork[0]); } }

42. Allowing Preemption • Allow a process to time-out on a blocked request -- withdrawing the request if it fails • r = request resource • w = withdraw request • d = release or deallocate resource ru Si Sj wu dv ru Sk

43. Allowing Preemption – cont. • No guarantee that this technique will be effective • System may come to set of states where a set of processes is polling for resources held by other processes in the set • Livelock, since there are transitions in the state diagram (so no deadlock), but none of these transitions are effective in the long run

44. Avoidance • Define a model of system states, then choose a strategy that will guarantee that the system will not go to a deadlock state • Requires extra information, e.g., the maximum claim for each process • Allows resource manager to see the worst case that could happen, then to allow transitions based on that knowledge

45. Deadlock Avoidance • Requires that the system has some additional a priori information available • Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need • The deadlock-avoidance algorithm dynamically examines the resource-allocation state to ensure that there can never be a circular-wait condition • Resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes

46. Safe State • When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state. • System is in safe state if there exists a safe sequence of all processes. • Sequence <P1, P2, …, Pn> is safe if for each Pi, the resources that Pi can still request can be satisfied by currently available resources + resources held by all the Pj, with j < i. • If Pi resource needs are not immediately available, then Pi can wait until all Pj have finished. • When Pj is finished, Pi can obtain needed resources, execute, return allocated resources, and terminate. • When Pi terminates, Pi+1 can obtain its needed resources, and so on.

47. Basic Facts • If a system is in safe state  no deadlocks. • If a system is in unsafe state  possibility of deadlock. • Avoidance  ensure that a system will never enter an unsafe state.

48. Comments on Safe State • It is a worst case analysis • If every process were to request its maximum claim, there would be a sequence of allocations and deallocations that could enable the system to satisfy every process’s request in some order • It does not mean that the system must have enough resources to simultaneously meet all the maximum claims

49. Likely to be in a safe state Probability of being in unsafe state increases More on Safe & Unsafe States Normal Execution No Request Max Claim Yes Execute, then release

50. More on Safe & Unsafe States Normal Execution No Request Max Claim Yes Execute, then release • Suppose all processes take “yes” branch • Avoidance strategy is to allow this to happen, yet still be safe