Concurrency: Deadlock and Starvation

1. Concurrency: Deadlock and Starvation Chapter 6

2. Deadlock • Permanent blocking of a set of processes • Normally due to the fact that they • wait for limited system resources for which they compete or • wait for messages • since messages can be seen as resources, in general it can be said that it is due to contention on resources. • There is no satisfactory solution in the general case • to determine whether a program contains a potential deadlock is a computationally unsolvable problem

3. Leading example for this chapter: • Consider a system that has a printer and a disk • Suppose two processes P1 and P2, which behave in the same way: • Pi starts by asking for either printer or disk, but will need to use both printer and disk later to finish • Consider the following sequence of events: • P1 asks for printer, gets it • P2 asks for disk, gets it • Now deadlock will occur when P1 and P2 claim the second resource they need to finish • By this example, it should be clear that there can be ways to avoid a deadlock and that if a deadlock occurs it is possible to recuperate from it

4. Details • Scenario not leading to deadlock: • P1 starts, takes the printer • P1 takes the disk, can complete • P2 now starts • We can select a good scenario if we can find out in advance: force a certain order of execution • But how to find out? Difficult: we must distinguish among • waiting for a resource that will arrive and • waiting for a resource that will never arrive • How to recover after detection? Possibility: suspend a process and take resources away from it

5. The Conditions for Deadlock • These 3 conditions of policy must be present for a deadlock to be possible (necessary conditions): • 1: Mutual exclusion • only one process may use a given resource at a time • 2: Hold-and-wait • a process may hold allocated resources while awaiting assignment of others • 3: No preemption • no resource can be forcibly removed from a process holding it

6. The Conditions for Deadlock • We also need the occurrence of a particular sequence of events that result in : • 4: Circular wait • a closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chain, such that • no process can complete without the resource held by the next

7. Relation between the 4 conditions mut. exclusion implies equivalent hold and wait deadlock circular wait no preemption

8. Aspects of handling deadlocks • Deadlock prevention • disallow 1 of the 3 necessary conditions of deadlock occurrence, or the equivalent condition • Deadlock avoidance • do not grant a resource request if this allocation might lead to deadlock • Deadlock detection and recovery • always grant resource requests when possible. But periodically check for the presence of deadlock and then recover from it

9. Deadlock Prevention • The OS is designed in such a way as to exclude a priori the possibility of deadlock • Indirect methods of deadlock prevention: • to disallow one of the 3 policy conditions • Direct methods of deadlock prevention: • to prevent the occurrence of circular wait

10. Mutual Exclusion cannot be disallowed ex: only 1 process at a time can write to a file or hold a block of memory. Hold-and-Wait can be disallowed by requiring that a process request all its resources at once block the process until all requests can be granted simultaneously but process may be held up for a long time waiting for all its requests so resources allocated to a process may remain unused for a long time. These resources could be used by other processes an application would need to be aware of all the resources that will be needed Indirect methods of deadlock prevention

11. Indirect methods of deadlock prevention • No preemption • Can be prevented in several ways. But whenever a process must release a resource whose usage is in progress, the state of this resource must be saved for later resumption. • Hence: practical only when the state of a resource can be easily saved and restored later, such as the processor.

12. Direct methods of deadlock prevention • A protocol to prevent circular wait: • define a strictly increasing linear ordering O() for resource types. Ex: • R1: tape drives: O(R1) = 2 • R2: disk drives: O(R2) = 4 • R3: printers: O(R3) = 7 • A process initially requests a number of instances of a resource type, say Ri. A single request must be issued to obtain several instances. • After that, the process can request instances for resource type Rj if and only if O(Rj) > O(Rn), where Rn is a resource type already granted

13. Applied to our leading example... • Deadlock cannot occur because we have decided that disk < printer, • so a process cannot ask for disk after having asked for printer

14. Prevention of circular wait • Circular wait cannot hold under this protocol. In the example below, either RA<RB, or RB<RA. Suppose RA<RB. The situation below can occur because P1 has obtained RB and then requested RA, while P2 has obtained RA and then requested RB. But P1 cannot request RA after RB.There are other cases, but they are symmetrical and are excluded by the same reasoning.

15. Prevention of circular wait • This protocol prevents deadlock but will often deny resources unnecessarily (inefficient) because of the ordering imposed on the requests

16. Deadlock Prevention: Summary • We disallow one of the 3 policy conditions or use a protocol that prevents circular wait • This leads to inefficient use of resources and inefficient execution of processes

17. Deadlock Avoidance • We allow the 3 policy conditions but make judicious choices to assure that the deadlock point is never reached • Allows more concurrency than prevention • Two approaches: • do not start a process if its demand might lead to deadlock • do not grant an incremental resource request if this allocation might lead to deadlock • In both cases: maximum requirements of each resource must be stated in advance

18. Resource allocation graphs (Silberschatz) • Process • Resource having 4 copies (instances) • Pi asks for one instance of Ri, of which we have 4 • Pj has been assigned one copy of Rj Pi Pi Rj

19. Example of resource allocation graphs:represents a state of the system P3 does not wait P1 waits P2 waits Possible deadlock?

20. Resource allocation graph with deadlock Cycles: P1  R1  P2  R3  P3  R2  P1 P2  R3  P3  R2  P2 cannot get out

21. Allocation graph with cycle but without deadlock (why?) Circular wait, but resources will become available

22. Observations • Cycles in a resource allocation graph do not necessarily imply a circular wait • If there is no cycle in the graph, no deadlock • If there are cycles: • If only one instance per resource type, deadlock • If several instances, possibility of deadlock • must ask question: is there a process that can terminate and if so, which other processes can terminate as a consequence?

23. Safe state • A state is safe if the system can get out of it without deadlock • In a safe state we can identify a sequence of process terminations, leading to a state where all processes terminate • Do not allocate a resource to a process if the resulting state is not safe

24. Deadlock detection • The system is allowed to enter a deadlock state • Deadlock is detected • There is recovery from deadlock • Detection of deadlock is not obvious: • if the OS sees some processes that wait, it cannot conclude that there is deadlock • there is deadlock only if there is a circular wait from which it is impossible to get out

25. Resource allocation graph and wait graph Is there deadlock? The second graph can be obtained from the first one

26. Resource types • Resources in a system are partitioned in resources types • Each resource type in a system exists with a certain amount. Let R(i) be the total amount of resource type i present in the system. Ex: • R(main memory) = 128 MB • R(disk drives) = 8 • R(printers) = 5 • The partition is system specific (ex: printers may be further partitioned...)

27. Symbol summary for this section • R(i) total amount of resource i in system • V(i) total available amount of resource i • W(i) temporary vector: available vector • U(i) total unclaimed amount of resource i • C(k,i) total claim of res. i by process k • A(j,i) amount of res. i allocated to proc. j • N(j,i) amount of res. i needed by proc. j • Q(j,i) amt. of res. i currently req. by proc j

28. Deadlock Detection • Resource access are granted to processes whenever possible. The OS needs: • an algorithm to check if deadlock is present • an algorithm to recover from deadlock • The deadlock check can be performed at every resource request • Such frequent checks consume CPU time

29. Trivial example of detection in our leading example • After each process has obtained 1M, the need of each process exceeds available memory (0M!). So no process can complete and there is a deadlock between P1 and P2.

30. A deadlock detection algorithm • Makes use of previous resource-allocation matrices and vectors • Marks each process not deadlocked. Initially all processes are unmarked. Then perform: • Mark each process j for which: A(j,i) = 0 for all resource type i. (since these are not deadlocked) • Initialize work vector: W(i) = V(i) for all i • REPEAT • Find an unmarked process j such that Q(j,i) <= W(i) for all i. Stop if such j does not exist. • If such j exists: mark process j and set W(i) = W(i) + A(j,i) for all i // Hoping that j will terminate • At the end: each unmarked process is deadlocked

31. Deadlock detection: comments • Process j is not deadlocked when Q(j,i) <= W(i) for all i. • Then we are optimistic and assume that process j will require no more resources to complete its task • It will thus soon return all of its allocated resources. Thus: W(i) = W(i) + A(j,i) for all i • If this assumption is incorrect, a deadlock may occur later • This deadlock will be detected the next time the deadlock detection algorithm is invoked

32. Deadlock detection: example Request Allocated Available • Mark P4 since it has no allocated resources • Set W = (0,0,0,0,1) • P3’s request <= W. So mark P3 and set W = W + (0,0,0,1,0) = (0,0,0,1,1) • Algorithm terminates. P1 and P2 are deadlocked R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 P1 P2 P3 P4 0 1 0 0 1 0 0 1 0 1 0 0 0 0 1 1 0 1 0 1 1 0 1 1 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1

33. Deadlock Recovery: after deadlock has been detected • Needed when deadlock is detected. The following approaches are possible: • Abort all deadlocked processes (one of the most common solutions adopted in OS!!) • Rollback each deadlocked process to some previously defined checkpoint and restart them (original deadlock may reoccur) • Successively abort deadlock processes until deadlock no longer exists (each time we need to invoke the deadlock detection algorithm)

34. Deadlock Recovery (cont.) • Successively preempt some resources from processes and give them to other processes until deadlock no longer exists • a process that has a resource preempted must be rolled back prior to its acquisition • For the 2 last approaches: a victim process needs to be selected according to (for ex.): • least amount of CPU time consumed so far • least total resources allocated so far • least amount of “work” produced so far...

35. An integrated deadlock strategy • We can combine the previous approaches into the following way: • Group resources into a number of different classes and order them. Ex: • Swappable space (secondary memory) • Process resources (I/O devices, files...) • Main memory... • Use prevention of circular wait to prevent deadlock between resource classes • Use the most appropriate approach for each class for deadlocks within each class

36. Important concepts of Chapter 6 • What is deadlock, what are its causes • Circular wait • Necessary conditions • Deadlock prevention: methods • Deadlock avoidance: methods • Deadlock detection: methods • Resource allocation graphs • Wait graphs