Concurrency Deadlock and Starvation Chapter 6 Deadlock Permanent

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 • No efficient solution • Involve conflicting needs for resources by two or more processes

Joint progress diagram • Paths 3 and 4 enter the gray-shaded area. – Referred to as a fatal region • If an execution path enters this fatal region, then deadlock is inevitable. • The existence of a fatal region depends on the logic of the processes. • Whether or not deadlock occurs depends on both the dynamics of the execution and on the details of the application.

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

Example of Deadlock

Another Example of Deadlock • Space is available for allocation of 200 K bytes, and the following sequence of events occur P 1 . . . Request 80 K bytes; P 2 . . . Request 70 K bytes; . . . Request 60 K bytes; Request 80 K bytes; • Deadlock occurs if both processes progress to their second request

Consumable Resources • Created (produced) and destroyed (consumed) by a process • 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

Example of Deadlock • Deadlock occurs if receive is blocking P 1 P 2 . . . Receive(P 2); Receive(P 1); Send(P 2, M 1); Send(P 1, M 2); . . .

Conditions for Deadlock • 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

Conditions for Deadlock • No preemption – No resource can be forcibly removed from a process holding it. – Preemption should not be arbitrary. – Must be supported by a rollback recovery mechanism.

Conditions for Deadlock • Circular wait

Dealing with Deadlocks • Three general approaches exist for dealing with deadlock: – Prevent, by adopting a policy that eliminates one of the four conditions. – Avoid, by making appropiate dynamic choices based on the current state of resource allocation. – Detect the presence of deadlock and take action to recover.

Deadlock Prevention (indirect) • Mutual exclusion: – Can not be disallowed. – If access to a resource requires mutual exclusion, then mutual exclusion must be supported.

Deadlock Prevention (indirect) • Hold and Wait: – Process requests all of its required resources at one time – Block process until all requests can be granted simultaneously. • • • Process may be held up for a long time waiting. Resources allocated may remain unused for a considerable period. Process may not know in advance all of the resources that it will require.

Deadlock Prevention (indirect) • No preemption: – If a process is denied a further request it must release its original resources. – If a process requests a resource held by another process, the OS may preempt the second process and require it to release its resources. – Only applies when the state of a resource can be easily saved and restored later.

Deadlock Prevention (direct) • Circular wait: – Define linear ordering of resource types. – If a process has been allocated resources of type Ri, then it may subsequently request only resources Rj, with i < j.

Deadlock Avoidance • Allows the three necessary conditions. • A decision is made dynamically whether the current resource allocation request will, if granted, potentially lead to a deadlock • Requires knowledge of future process request

Two Approaches to Deadlock Avoidance • Do not start a process if its demands might lead to deadlock • Do not grant an incremental resource request to a process if this allocation might lead to deadlock

Resource Allocation Denial • Referred to as the banker’s algorithm • State of the system is the current allocation of resources to process • Safe state is where there is at least one sequence that does not result in deadlock • Unsafe state is a state that is not safe

Algoritmo del banquero 1. Para cada petición de recurso, verificar que el proceso que la realiza está autorizado a presentar la petición en virtud de tener un número suficiente de reclamaciones no efectuadas sobre el tipo solicitado de recurso. (Rehusar peticiones no autorizadas).

Algoritmo del banquero 1. Si un proceso solicita un recurso que no está disponible para asignación, suspender al proceso solicitante hasta que la petición pueda ser concedida con seguridad. 2. Si un proceso solicita un recurso disponible, pretender que el recurso le es concedido actualizando las estructuras de datos ASIGNADOS, NECESIDAD y DISPONIBLES. 3. Desmarcar todos los procesos.

Algoritmo del banquero 1. Hallar un proceso i desmarcado tal que: NECESIDADi <= DISPONIBLES Si se encuentra, marcar el proceso i, actualizar el vector DISPONIBLES: DISPONIBLES=DISPONIBLES+ASIG NADOSi Repetir este paso mientras puedan encontrarse procesos que califiquen.

Algoritmo del banquero 1. Si todos los procesos están marcados, el estado del sistema es seguro; por tanto, asignar el recurso solicitado. Restaurar el vector DISPONIBLES a su valor establecido en el paso 2 y salir. En caso contrario, el estado del sistema no es seguro, y por tanto suspender el proceso solicitante, restaurar ASIGNADOS, NECESIDAD y DISPONIBLES a sus valores anteriores a la ejecución del Paso 2 y salir.

Determination of a Safe State Initial State (P 2 req 0 -0 -1)

Determination of a Safe State P 2 Runs to Completion

Determination of a Safe State P 1 Runs to Completion

Determination of a Safe State P 3 Runs to Completion

Determination of an Unsafe State (P 1 req 1 -0 -1)

Determination of an Unsafe State

P 1 pide 1 -1 -0 R 1 R 2 R 3 P 1 3 6 5 P 2 3 2 P 3 6 P 4 P 5 R 1 R 2 R 3 P 1 0 0 0 5 P 2 1 1 1 3 3 P 3 2 2 1 4 2 4 P 4 0 1 1 2 0 2 P 5 2 2 2 necesidad 3 1 disponibles asignados 2 8 7 total recursos 7

Deadlock Avoidance • 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

Deadlock Detection • Request matrix Q, such that Qij represents the amount of resources of type j requested by process i. A is allocation matrix. • Initially all process are unmarked. – 1. Mark each process that has a row in the Allocation matrix of all zeros. – 2. Initialize W=V (Available) – 3. Find an i such that Pi is unmarked and Qik<=Wk for k=1…m, if none found terminate. – 4. If such i is found, mark process i and set Wk=Wk+Aik for k=1…m. Return to step 3

Deadlock Detection

Strategies once Deadlock Detected • Abort all deadlocked processes • Back up each deadlocked process to some previously defined checkpoint, and restart all process – original deadlock may occur • Successively abort deadlocked processes until deadlock no longer exists • Successively preempt resources until deadlock no longer exists

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