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

Here it is!...

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 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 Examples: CPU, memory, files, databases, and semaphores

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

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 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 can’t do anything about this 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 “Hold & wait” 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 preempt the second process and require it to release its resources (  waste of CPU and other resources) Can only be used in very special circumstances DEADLOCK PREVENTION “No preemption” condition

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

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 R x if R i < R x for  R i the process is currently holding

Circular Wait P(process) holds R(resource) P requests R Prevented by defining a linear ordering of resources! i.e. R 1 < R 2 < …. < R k-1 < R k P R P R PiPi.. RyRy RxRx P i+1 RzRz RkRk

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 Denial 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 that does not result in deadlock Unsafe state : a state that is not 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 Is this state Safe ?

When should we grant a request ? 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! For one moment, assume that we granted P1’s request for (R1 & R3)  P1

Maximum resource requirement for each process must be stated in advance Processes under consideration must be independent and with no synchronization requirements There must be a fixed number of resources to allocate No process may exit while holding resources

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

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

Mechanisms to facilitate Concurrency in UNIX / Linux Shared memory Signals Pipes Messages Threads Semaphores THREAD SYNCHRONIZATION PRIMITIVES (POSIX) Mutual exclusion (mutex) locks pthread_mutex_lock() pthread_mutex_trylock() pthread_mutex_unlock() Condition variables pthread_cond_wait() pthread_cond_signal()