Chapter 6 Concurrency: Deadlock and Starvation

Transcription

1 Operating Systems: Internals and Design Principles Chapter 6 Concurrency: Deadlock and Starvation Seventh Edition By William Stallings Edited by Rana Forsati CSE410

2 Outline Principles of deadlock Deadlock prevention Deadlock avoidance Deadlock detection

3 The Deadlock Problem (I) The permanent blocking of a set of processes that either compete for a resource or communicate each other prevent sets of concurrent processes from completing their tasks

4 The Deadlock Problem (II) A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set Example 1 System has 2 disk drives P 1 and P 2 each hold one disk drive and each needs another one Example 2 semaphores A and B, both initialized to 1 P 0 P 1 wait (A); wait (B); wait(b) wait(a)

5 Deadlock and Dining Philosophers - Consider a proposal in which each philosopher is instructed to behave as follows: think until the left fork is available; when it is, pick it up; think until the right fork is available; when it is, pick it up; when both forks are held, eat for a fixed amount of time; then, put the right fork down; then, put the left fork down; repeat from the beginning. This attempted solution fails because it allows the system to reach a deadlock state, in which no progress is possible [ philosophers will die :-) ]. Wikipedia:

6 Deadlock Involve conflicting needs for resources by two or more processes Permanent: none of the process can continue execution No efficient solution

7 Resource Categories Reusable resource Consumable resource

8 Reusable Resources Used by one process at a time and not depleted by that use Processes obtain resources that they later release for reuse by other processes Processors, I/O channels, main and secondary memory, files, databases, and semaphores Deadlock occurs if each process holds one resource and requests the other Main focus in this course

9 Reusable Resource Deadlock Space is available for allocation of 200Kbytes, and the following sequence of events occur: P1... Request 80 Kbytes;... Request 60 Kbytes; P2... Request 70 Kbytes;... Request 80 Kbytes; Deadlock occurs if both processes progress to their second request

10 Consumable Resources Created (produced) and destroyed (consumed) by a process No limit on the number of consumable resources of one type Interrupts, signals, messages, and information in I/O buffers Deadlock may occur if a Receive message is blocking May take a rare combination of events to cause deadlock

11 Resource Allocation Graphs deadlock deadlock-free

12 Four Conditions for Deadlock Deadlocks can arise if four conditions hold simultaneously: Mutual exclusion only one process may use a resource at a time Hold-and-wait A process may hold allocated resources while awaiting assignment of other resources No preemption No resource can be forcibly removed from a process holding it Circular waiting - given that the first three conditions exist, a sequence of events may occur that lead to an unresolvable circular wait The first three conditions are necessary but not sufficient for a deadlock to exist. For deadlock to actually take place, circular waiting is required!

13 Circular Waiting The circular waiting condition is, actually, a potential consequence of the first three, and taken together, constitute necessary and sufficient conditions for deadlock A closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chain Circular wait: there exists a chain {P 0, P 1,,P N, P 0 } of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2,, P n 1 is waiting for a resource that is held by P n, and P n is waiting for a resource that is held by P 0.

14 Dealing with Deadlock Ensure that the system will never enter a deadlock state Deadlock Prevention methods Deadlock Avoidance methods Allow the system to enter a deadlock state and then recover Deadlock Detection method

15 Dealing with Deadlock Deadlock Prevention Adopting a policy that eliminates one of the conditions [aggressive] Deadlock Avoidance Making appropriate dynamic choices based on the current state of resource allocation [conservative] Deadlock Detection Detect deadlock and take action to recover [reasonable]

16 Outline Principles of deadlock Deadlock prevention Deadlock avoidance Deadlock detection

17 Deadlock Prevention Strategy Design a system in such a way that the possibility of deadlock is excluded. Two main methods: Indirect prevent the occurrence of one of the three necessary conditions Direct prevent the occurrence of a circular wait

18 Deadlock Prevention Elimination of Mutual Exclusion: if access to a resource requires mutual exclusion then it must be supported by the OS. Cannot be disallowed Elimination of Hold and Wait Can be prevented by A process requests all the required resources at one time Blocking the process until all requests can be granted simultaneously Problems: Inefficient A process maynot know in advance all resources it will require.

19 Deadlock Condition Prevention Elimination of No Preemption If a process holding certain resources is denied a further request, that process must release its original resources and request them again If a process requests a resource held by another process, OS may preempt the second process and require it to release its resources Only works when resource state can be saved and restored later.

20 Deadlock Condition Prevention With this rule, the resource allocation graph can never have a cycle. Elimination of Circular Wait Define a linear ordering of resource types If a process has been allocated resources of type R, then it may subsequently request only those resources of types following R in the ordering. May be inefficient, slowing down processes and denying resource access unnecessarily 1 Card reader 2 Printer 3 Plotter 4 Tape drive 5 Card punch Processes can request resources whenever they want to, but all requests must be made in numerical order. aggressive and is inefficient.

21 Outline Principles of deadlock Deadlock prevention Deadlock avoidance Deadlock detection

22 Deadlock Avoidance Can we guarantee that deadlocks will never occur? Allow the three necessary conditions but makes judicious choices to assure that the deadlock point is never reached A decision is made dynamically whether the current resource allocation request will, if granted, potentially lead to a deadlock Avoidance allows more concurrency than prevention. Requires knowledge of future process requests only works when resource state can be saved and restored later.

23 Deadlock Avoidance Referred to as the banker s algorithm Consider a system with a fixed number of processes and a fixed number of resources. At any time a process may have zero or more resources allocated to it. When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state A state is safe if the system can allocate resources to each process (up to its maximum) in some order and still avoid a deadlock. Safe state is where there is at least one sequence of resource allocations to all processes that does not result in a deadlock We are considering a worst-case situation here. Even in the worst case (process requests up their maximum at the moment), we don t have deadlock in a safe state. Unsafe state is a state that is not safe

24 Safe State More formally: A system state is safe if there exists a safe sequence of all processes (<P 1, P 2,, P n >) such that for each P i, the resources that P i can still request can be satisfied by currently available resources + resources held by all the P j, with j < i That is: If P i resource needs are not immediately available, then P i can wait until all P j have finished When P j is finished, P i can obtain needed resources, execute, return allocated resources, and terminate When P i terminates, P i +1 can obtain its needed resources, and so on.

25 Resource Allocation Denial If system is in safe state no deadlock If system is in unsafe state possibility of deadlock Avoidance ensure that system will never enter an unsafe state UNSAFE DEADLOCK SAFE Only with luck will processes avoid deadlock. O.S. can avoid deadlock.

26 The State of System There are n processes and m resources, and OS knows: Number of available instances of each resource For each process, current amount of each resource it owns For each process, maximum amount of each resource it might ever need declared in advance

27 Deadlock Avoidance: Assumptions When a request is done by a process for some resource(s): check before allocating resource(s); if it will leave the system in an unsafe state, then do not allocate the resource(s); process is waited and resources are not allocated to that process. The system knows the complete sequence of requests and releases for each process The system decides for each request whether or not the process should wait in order to avoid a deadlock Each process declare the maximum number of resources of each type that it may need in future The system should always be at a safe state Safe state no deadlock

28 Banker s Algorithm Key idea: ensure that the system of processes and resources is always in a safe state Mechanism: when a process makes a request for a set of resources Assume that the request is granted Update the system state accordingly Determine if the result is a safe state If so, grant he request; if not, block the process until it is safe to grant the request

29 Date Structure for Banker s Algorithm Resource or Existing-- vector representing the total number of each type of resource in the system Available -- vector representing the number of each type of resource not allocated to any process Claim or Max -- matrix representing the maximum number of each type of resource that each process may request Allocation -- matrix representing the number of each type of resource currently allocated to each process Need -- matrix representing the difference between the Claim and Allocation matrices Request -- vector representing a request for additional resources from a given process

30 An example system state All resources in the system Existing or Resource A B C Max A B C P P P P P Allocation A B C P P P P P system state at some t (may change) Need = Max - Allocation Need A B C P P P P P Available A B C 3 3 2

31 Notation X A B C P P P P P X is a matrix. X i is the i th row of the matrix: it is a vector. For example, X 3 = [2 1 1] Compare two vectors: Ex: compare V with X i V X i V A B C V is a vector; V = [3 3 2] V == X i? V <= X i? X i <= V?. Ex: Compare [3 3 2] with [2 2 1] [2 2 1] <= [3 3 2]

32 Resource-Request Algorithm for Process P i Request: request vector for process P i. If Request i [j] == k, then process P i wants k instances of resource type R j Algorithm 1. If Request i Need i go to step 2. Otherwise, raise error condition, since process has exceeded its maximum claim 2. If Request i Available, go to step 3. Otherwise P i must wait, since resources are not available

33 Resource-Request Algorithm for Process P i 3. Pretend to allocate requested resources to P i by modifying the state as follows: Available = Available Request i ; Allocation i = Allocation i + Request i ; Need i = Need i Request i ; Run the Safety Check Algorithm: If safe the requested resources are allocated to P i If unsafe The requested resources are not allocated to P i. P i must wait. The old resource-allocation state is restored.

34 Banker s Algorithm 1. If request[i] > need[i] then error (asked for too much) 2. If request[i] > available[i] then wait (can t supply it now) 3. Resources are available to satisfy the request Let s assume that we satisfy the request. Then we would have: available = available - request[i] allocation[i] = allocation [i] + request[i] need[i] = need [i] - request [i] Now, check if this would leave us in a safe state: if yes, grant the request, if no, then leave the state as is and cause process to wait.

35 Determination of a Safe State Initial State State of a system consisting of four processes and three resources Allocations have been made to the four processes

36 P2 Runs to Completion

37 P1 Runs to Completion

38 P3 Runs to Completion Thus, the state defined originally is a safe state

39 Example (I) of Banker s Algorithm We have the following system state: Need = Max - Allocation Max A B C Allocation A B C Need A B C Available A B C P P P P P P P P P P P P P P P Is it a safe state?

40 Example (I) of Banker s Algorithm Allocation A B C Need A B C Available A B C P P P P P P P P P P Try to find a row in Need i that is <= Available P1. run completion. Available becomes = [3 3 2] + [2 0 0] = [5 3 2] P3. run completion. Available becomes = [5 3 2] + [2 1 1] = [7 4 3] P4. run completion. Available becomes = [7 4 3] + [0 0 2] = [7 4 5] P2. run completion. Available becomes = [7 4 5] + [3 0 2] = [10 4 7] P0. run completion. Available becomes = [10 4 7] + [0 1 0] = [10 5 7] We found a sequence of execution: P1, P3, P4, P2, P0. State is safe

41 Example: P 1 requests (1,0,2) At that time Available is [3 3 2] First check that Request Available (that is, (1,0,2) (3,3,2) true. Then check the new state for safety: Max A B C Allocation A B C Need A B C Available A B C P P P P P P P P P P P P P P P new state (we did not go to that state yet; we are just checking)

42 Example: P 1 requests (1,0,2) Allocation A B C P P P P P Need A B C P P P P P Available A B C new state Can we find a sequence? Run P1. Available becomes = [5 3 2] Run P3. Available becomes = [7 4 3] Run P4. Available becomes = [7 4 5] Run P0. Available becomes = [7 5 5] Run P2. Available becomes = [10 5 7] Sequence is: P1, P3, P4, P0, P2 Yes, New State is safe. We can grant the request. Allocate desired resources to process P1.

43 P 4 requests (3,3,0)? Allocation A B C P P P P P Need A B C P P P P P Available A B C Current state If this is current state, what happens if P4 requests (3 3 0)? There is no available resource to satisfy the request. P4 will be waited.

44 P 0 requests (0,2,0)? Should we grant? Allocation A B C P P P P P Need A B C P P P P P Available A B C Current state System is in this state. P0 makes a request: [0, 2, 0]. Should we grant.

45 P 0 requests (0,2,0)? Should we grant? Assume we allocate 0,2,0 to P0. The new state will be as follows. Allocation A B C P P P P P Need A B C P P P P P Available A B C New state Is it safe? No process has a row in Need matrix that is less than or equal to Available. Therefore, the new state would be UNSAFE. Hence we should not go to the new state. The request is not granted. P0 is waited.

46 Example(II) of Banker s Algorithm

47 Example(II) of Banker s Algorithm

48 Example(II) of Banker s Algorithm

49 Example(II) of Banker s Algorithm

50 Banker s Algorithm n: integer # of processes m: integer # of resources available[1..m] - available[i] is # of avail resources of type i claim[1..n,1..m] - max demand of each Pi for each Ri allocation[1..n,1..m] - current allocation of resource Rj to Pi need[1..n,1..m] max # resource Rj that Pi may still request let request[i] be vector of # of resource Rj Process Pi wants

51 Banker s Algorithm 1. If request[i] > need[i] then error (asked for too much) 2. If request[i] > available[i] then wait (can t supply it now) 3. Resources are available to satisfy the request Let s assume that we satisfy the request. Then we would have: available = available - request[i] allocation[i] = allocation [i] + request[i] need[i] = need [i] - request [i] Now, check if this would leave us in a safe state: if yes, grant the request, if no, then leave the state as is and cause process to wait.

52 Deadlock Avoidance Advantages It is not necessary to preempt and rollback processes, as in deadlock detection It is less restrictive than deadlock prevention

53 Example (III) Assume we have the following resources: 5 tape drives 2 graphic displays 4 printers 3 disks We can create a vector representing our total resources: Total = (5, 2, 4, 3).

54 Example(III) Consider we have already allocated these resources among four processes as demonstrated by the following matrix Process Name Tape Drives Graphics Printers Disk Drives Process A Process B Process C Process D We also need a matrix to show the number of each resource still needed for each process; Process Name Tape Drives Graphics Printers Disk Drives Process A Process B Process C Process D Available = (1, 0, 2, 0). Question: Show that the sequence <D, A, B, C> safe state?

55 Deadlock Avoidance? Restrictions on its use: Maximum resource requirement must be stated in advance Processes under consideration must be independent; no synchronization requirements There must be a fixed number of resources to allocate No process may exit while holding resources

56 Outline Principles of deadlock Deadlock prevention Deadlock avoidance Deadlock detection

57 Deadlock Strategies Deadlock prevention strategies are very conservative limit access to resources by imposing restrictions on processes Deadlock detection strategies do the opposite resource requests are granted whenever possible

58 Deadline Detection Algorithms Do not limit resource access or restrict process actions Requested resources are granted to processes whenever possible OS periodically performs detection algorithm Algorithm similar to that for detecting safe state can be used for deadlock detection as well. If deadlock is detected, it is fixed by OS!

59 Deadline Detection Algorithms A check for deadlock can be made as frequently as each resource request or, less frequently, depending on how likely it is for a deadlock to occur Advantages: it leads to early detection the algorithm is relatively simple Disadvantage frequent checks consume considerable processor time

60 Date Structure for Detection Algorithm Resource -- vector representing the total number of each type of resource in the system Available -- vector representing the number of each type of resource not allocated to any process Allocation -- matrix representing the number of each type of resource currently allocated to each process Request matrix representing the current request of each process

61 F: unmarked T: marked Example Marked = {F, F, F, F}; Available = (0, 0, 1); W is initialized to (0, 0, 1) R 1 R 2 R 3 P P P P Allocation A R 1 R 2 R 3 P P P P Request Q Q(P3) = (0, 0, 1) <= (0, 0, 1) = W

62 Example Marked = {F, F, T, F}; W = (1, 1, 1) = (0, 0, 1) + (1, 1, 0) R 1 R 2 R 3 P P P P Allocation A R 1 R 2 R 3 P P P 3 P Request Q

63 Example Marked = {F, F, T, T}; W = (2, 2, 2) = (1, 1, 1) + (1, 1, 1); R 1 R 2 R 3 P P P P Allocation A R 1 R 2 R 3 P P P 3 P 4 Request Q

64 Example Marked = {F, T, T, T}; W = (4, 3, 2) = (2, 2, 2) + (2, 1, 2); R 1 R 2 R 3 P P P P Allocation A R 1 R 2 R 3 P P 2 P 3 P 4 Request Q

65 Example Marked = {T, T, T, T}; W = (5, 4, 3) = (4, 3, 2) + (1, 1, 1); R 1 R 2 R 3 R 1 R 2 R 3 P P P P P 1 P 2 P 3 P 4 Allocation A Request Q

66 Detection Algorithm

67 Recovery Strategies Once deadlock has been detected, some strategy is needed for recovery. The following are possible approaches, listed in order of increasing sophistication: Abort all deadlocked processes Back up each deadlocked process to some previously defined checkpoint and restart all processes Successively abort deadlocked processes until deadlock no longer exists Successively preempt resources/processes until deadlock no longer exists Successively means an order is followed: least amount of CPU time consumed, lowest priority, least total resources allocated so far, etc.

68 Selection Criteria Deadlocked Processes Least amount of processor time consumed so far Least number of lines of output produced so far Most estimated time remaining Least total resources allocated so far Lowest priority

69 An Integrated Deadlock Strategy It might be more efficient for OS to use different strategies in different situations. One approach: Group resources into a number of different resource classes Use linear ordering strategy defined previously for the prevention of circular wait to prevent deadlocks between resources classes Within a resource class, use the algorithm that is most appropriate for that class

70 Deadlock: Summary the blocking of a set of processes that either compete for system resources or communicate with each other blockage is permanent unless OS takes action may involve reusable or consumable resources Consumable = destroyed when acquired by a process Reusable = not depleted/destroyed by use Dealing with deadlock: prevention guarantees that deadlock will not occur detection OS checks for deadlock and takes action avoidance analyzes each new resource request