Concurrency: Deadlock and Starvation Chapter 6

Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate with each other Involve conflicting needs for resources by two or more processes No efficient solution to detect or break a deadlock

Here it is!...

REUSABLE RESOURCES CONSUMABLE 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 Examples: CPU, memory, files, databases, and semaphores CONSUMABLE RESOURCES Created (produced) and destroyed (consumed) by a process Ex: Interrupts, signals, messages, and information in I/O buffers Deadlock may occur if a Receive message is blocking

Deadlock Example (reusable resource) Space is available for allocation of 200K bytes, and the following sequence of events occur P2 …. Request 70 KB Request 85 KB … Release 70 KB Release 85 KB P1 …. Request 80 KB Request 60 KB … Release 80 KB Release 60 KB

Deadlock Example (reusable resource) Space is available for allocation of 200K bytes, and the following sequence of events occur Deadlock occurs if both processes progress to their second request P2 …. Request 70 KB Request 85 KB … Release 70 KB Release 85 KB P1 …. Request 80 KB Request 60 KB … Release 80 KB Release 60 KB

Deadlock Example (consumable resource) Deadlock occurs if Receive is blocking P1 …. Receive(P2); Send(P2, Message1) P2 …. Receive(P1); Send(P1, Message2)

Addressing Deadlock Prevention Avoidance Detection & Recovery Design the system so that deadlock is impossible Avoidance Construct a model of system states, then choose a strategy that, when resources are assigned to processes, will not allow the system to go to a deadlock state Detection & Recovery Check for deadlock (periodically or sporadically), then recover Manual intervention Have the operator reboot the machine if it seems too slow

Deadlock Prevention Deadlock implies Mutual exclusion Hold and wait No preemption Circular waiting If we can ensure that at least one of these conditions is false at all times, then deadlock can be prevented In other words, No Mutual Exclusion  No Deadlock No (Hold & Wait)  No Deadlock Preemption allowed  No Deadlock No (Circular Wait)  No Deadlock Also (Circular Wait)  Deadlock

DEADLOCK PREVENTION “Mutual exclusion” condition only one process may use a resource at a time To prevent deadlock  do not require “mutual exclusion” If this is a resource constraint, then mutual exclusion must hold at all times. (i.e. you are not allowed to change it!)

DEADLOCK PREVENTION “Hold & wait” condition To prevent deadlock  avoid 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

DEADLOCK PREVENTION “No preemption” condition To prevent deadlock  allow preemption ! If a process holding certain resources is denied a further request, that process must release its original resources ( inefficient !) If a process requests a resource that is held by another process, the OS may force the latter process to release its resources ( waste of CPU and other resources) Can only be used in very special circumstances

DEADLOCK PREVENTION “Circular wait” condition **here DEADLOCK PREVENTION “Circular Wait” condition To prevent deadlock  don’t go into a circular wait situation!

Circular Wait (cont.) For deadlock to occur, there must be a cycle in the graph of processes and resources Choose a resource request strategy by which no cycle will be introduced Create a total order on all resources. Then a process can only ask for Rx if Ri < Rx for Ri the process is currently holding

Circular Wait .. Prevented by defining a linear ordering of resources! i.e. R1 < R2 < …. < Rk-1 < Rk Pi .. Ry Rx Pi+1 Rz Rk P R P(process) holds R(resource) P R P requests R

Addressing Deadlock Prevention Avoidance Detection & Recovery Design the system so that deadlock is impossible Avoidance Construct a model of system states, then choose a strategy that, when resources are assigned to processes, will not allow the system to go to a deadlock state Detection & Recovery Check for deadlock (periodically or sporadically), then recover Manual intervention Have the operator reboot the machine if it seems too slow

Deadlock 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 Resource manager tries to see the worst case that could happen. It does not grant an incremental resource request to a process if this allocation might lead to deadlock REQUIREMENTS Max. resource requirement must be stated in advance There must be a fixed number of resources to allocate Processes under consideration must be independent; no synchronization requirements No process may exit while holding resources

Resource Allocation Criteria Referred to as the Banker’s algorithm State of the system is the current allocation of resources to processes Safe state : there is at least one sequence of actions (scenario) that does not result in deadlock; i.e. all of the processes could run to completion. Unsafe state : a state that is not safe Do not grant a request if it leads to an unsafe state.

Is this state Safe ?

Is this state Safe ?

Is this state Safe ? Yes, the given state is SAFE ! Because there is at least one scenario in which all processes can finish: P2, P1, P3, and P4

When should we grant a request ? For one moment, assume that we granted P1’s request for (R1 & R3)  P1 Q: If P1 requests 1 unit each of R1 and R3, should we grant it? A: No! Because, there is a possibility that a deadlock may occur!

Deadlock Detection 1. P4 is not deadlocked because it’s Allocation vector is 00000. 2. Available vector = (0 0 0 0 1) 3. P3’s request vector  (0 0 0 0 1) so mark P3 as “not deadlocked”, and release its resources Now, Available vector = (0 0 0 1 1) 4. Unfortunately, no other process has a row  Available vector 5. Therefore ====> P1 and P2 are deadlocked!

Strategies once Deadlock is Detected Abort all deadlocked processes Back up each deadlocked process to some previously defined checkpoint, and restart. original deadlock may occur Successively abort deadlocked processes until deadlock no longer exists Successively preempt resources until deadlock no longer exists Some Criteria for terminating a deadlocked process Least amount of processor time consumed so far Most estimated time remaining Least total resources allocated so far Lowest priority

Summary of Approaches: Deadlock Prevention, Avoidance, and Detection There is no single effective strategy that can deal with all types of deadlock. Table 6.1 summarizes the key elements of the most important approaches that have been developed: prevention, avoidance, and detection. We examine each of these in turn, after first introducing resource allocation graphs and then discussing the conditions for deadlock.