Deadlocks (Chapter 7)

Available (Banker's)

- A vector of length m - If available[j] = k, there are k instances of resource type Rj available

Deadlock Recovery: Process Termination

- Abort all deadlocked processes - Abort one process at a time until the deadlock cycle is eliminated - In which order should we choose to abort? -- Priority of the process -- How long process has computer, and how much longer to completion -- Resources the process has used -- Resources process needs to complete -- How many processes will need to be terminated -- Is process interactive or batch?

Banker's Algorithm Data Structures

- Available - Max - Allocation - Need

Deadlock Detection Data Structures

- Available: A vector of length m indicates the number of available resources of each type - Allocation: An n x m matrix defines the number of resources of each type currently allocated to each process - Request: An n x m matrix indicates the current request of each process -- If request[i][j] = k, then process Pi is requesting k more instances of resource type Rj

Safe State Facts

- If a system is in a safe state there can be no deadlocks - If a system is in an unsafe state, there is a possibility of deadlocks - You want to ensure a system never enters an unsafe state; this is the purpose of Avoidance

Hold and Wait (Prevention)

- Must guarantee that whenever a process requests a resource, it does not hold any other resources - Requires processes to request and be allocated all their resources before they begin -- Or allow processes to request resources only when they have no resources allocated to them. - Sadly lowers resource utilization and makes starvation possible

Deadlock Recovery: Resource Termination

- Selecting a victim - minimize cost - Rollback - return to some safe state, restart process for that state - Starvation - same process may always be picked as victim, so include the number of rollbacks in cost factor

Resource-Allocation State

- The number of available and allocated resources; - The maximum demands of the processes

Allocation

- n x m matrix - If Allocation[i, j] = k, then Pi is currently allocated k instances of Rj

Max

- n x m matrix - If Max[i, j] = k, then process Pi may request at most k instances of resource type Rj

Need

- n x m matrix - If Need[i, j] = k, then Pi may need k more instances of Rj to complete its task - Need[i, j] = Max[i, j] - Allocation[i, j] (Need = Max - Allocation)

Resource Request and Release System Calls

- request() and release() device - open() and close() file - allocate() and free() memory - wait() and signal() on semaphores - acquire() and release() of mutex locks Semaphores and mutex locks are for resources not already managed by the OS (And therefore not having built-in system calls)

Banker's Algorithm Process

1. Let Work and Finish be vectors of length m and n, respectively - Work = Available - Finish[i] = false for i = 0, 1, ..., n-1 2. Find an i such that both: - Finish[i] = false - Needi <= Work - If no such i exists, go to step 4 3. Work = Work + Allocationi - Finish[i] = true - Go to step 2 4. If Finish[i] == true for all i, then the system is in a safe state

Detection Algorithm Process

1. Let Work and Finish be vectors of length m and n, respectively. Initialize Work = Available. - For i = 0, 1, ..., n-1, if Allocation /= 0, then Finish[i] = false. Otherwise, Finish[i] = true 2. Find an index i such that both: - Finish[i] == false - Requesti <= Work - If no such i exists, go to step 4 3. Work = Work + Allocationi - Finish[i] = true - Go to step 2 4. If Finish[i] == false for some i, 0 <= i <= n, then the system is in a deadlocked state - Moreover, if Finish[i] == false, then process Pi is deadlocked

Detection-Algorithm Usage

1. When and how often to invoke depends on: - How often are deadlocks likely to occur? - How many processes will need to be rolled back? -- One for each disjoin cycle 2. If the detection algorithm is invoked arbitrarily - There may be many cycles in the resource graph -- Thus, would not be able to tell which of the many deadlocked processes "caused" the deadlock

Deadlock Conditions

A deadlock situation can arise if the following for conditions are simultaneously true in the system 1. Mutual exclusion 2. Hold and wait 3. No preemption 4. Circular wait Circular weight implies holding weight, so the four conditions are not completely independent

System Resource Allocation Graph

A graph used to describe deadlocks. It consists of a set of vertices V and a set of edges E. - V is partitioned into two different types of notes: P, the SAP consisting of all the active processes in the system and R, the set consisting of all resource types in the system - P1 -> R2 signifies that Process 1 has requested an instance of Resource Type 2 — Called a request edge - R2 -> P1 signifies that an instance of Resource Type 2 has been allocated to Process — Called an assignment edge - processes are depicted as circles while resources are depicted as rectangles. The number of dots inside the rectangle indicates the number of instances for that resource type - If the graph contains no cycles, then no process in the system is deadlocked. If there are multiple instances of resource type, it may take multiple cycles of that resource to create a deadlock

Hold and Wait Condition

A process must be holding at least one resource and waiting to acquire additional resources that are currently being held by other processes

Deadlocked Set/State

A set of processes is in a deadlock state when every process in the set is waiting for an event that can be caused only by another process in the set.

System Model

A system consist of a finite number of resources to be distributed among a number of competing processes. The resources are partitioned into several types, each consisting of some number of identical instances - If a process request an instance of a resource type, the allocation of any instance of that type will satisfy the request - A process must request a resource before using it and release it after it's done using it - a process may request as many resources as it requires to carry out its task, though obviously the number requested may not exceed the total number available in the system, as this would be impossible

Mutual Exclusion Condition

At least one resource must be held in a non-shareable mode; that means only one process at a time can use the resource. If another process requests it, the requesting process is delayed until the resource is released

Safe State

Exists if there is a sequence <P1, P2, ..., Pn> of ALL the processes in the systems such that for each Pi, the resources Pi can still request can be satisfied by the currently available resources + the resources held by all Pj, where j < i (If what Pi needs is not entirely available yet, it can safely wait for Pj to finish and release the resources) - When a process requests an available resource, the system must decide if immediate allocation lets it remain in a safe state

Kernel-Managed Resource Use

For each such resource used by a process or thread, the operating system checks to make sure that the process has requested I've been allocated the resource - assistant table record whether each resource is free or allocated; for each resource that is allocated, the table also records the process to which it is allocated - If the requested resources in use, the process can be added to a Q of processes waiting for it

Methods for Handling Deadlocks

Generally speaking we can deal with deadlocks in one of three ways - we can use a protocol to prevent or avoid that locks, ensuring that the system will never enter a deadlocked state - we can allow the system to enter a deadlocked state, detected, and recover - we could ignore the problem altogether and pretend the deadlocks never occur in the system — Ironically the third solution is the one used by most operating systems; that it's up to the application developer to write programs that handled that deadlocks These methods can be combined for better, more flexible systems

No Preemption (Prevention)

If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources being held are released - Preempted resources are added to the list of resources which the process is waiting - Processes will be restarted only when they can regain their old resources, as well as any new ones it is requesting

Deadlocks across Resource Types

Imagine a system where there is one DVD drive in one printer. Process 1 holds the printer while process 2 holds the DVD drive. 1 then requests the DVD drive while 2 requests the printer.

Circular Wait (Prevention)

Impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration - Can only request an instance of resource type Ri if F(Ri) > F(Ri-1), where F is the enumeration system

Deadlock Characterization

In a deadlock processes never finish executing and system resources are tied up, preventing other jobs from starting

Deadlock Recovery Algorithms

In a system without deadlock prevention or deadlock avoidance, deadlock may occur. In this situation the system can provide an algorithm that examines the state of the system to determine whether the deadlock has actually occurred, and another algorithm to recover from the deadlock - Without at least these eventually the deadlock will spread in the system performance will deteriorate until it's almost completely stops functioning it must be restarted

Banker's Algorithm Notations

Let X and Y be vectors of length n - X <= Y if and only if X[i] <= Y[i] for all i = 1, 2, ..., n - Y < x if Y <= X and Y /= X - Each row in the Allocation matrix: Allocationi -- Specifies resources currently allocated to Process Pi - Each row in the Need matrix: Needi -- Specifies the additional resources process Pi may still request to complete its task

Deadlock Detection (Single Instance of Each Resource Type)

Maintain a wait-for graph - Nodes are processes - Pi -> Pj if Pi is waiting for Pj Periodically invoke an algorithm that searches for a cycle in the graph. If there is a cycle, there exists a deadlock - Such an algorithm requires an order of n^2 operations, where n is the number of vertices in the graph

Resource Types

Memory space, CPU cycles, files, I/O devices, CPUs, etc. - Mutex locks and semaphores are also considered system resources to protect: Access to a queue, a linked list, etc. -- These are a very common source of deadlocking

Mutual Exclusion (Prevention)

Processes must hold for non-sharable resources - Not required for sharable resources (i.e. read-only files)

Deadlock Prevention

Provides a set of methods for ensuring that at least one of the necessary conditions for a deadlock cannot hold

Banker's Resource-Request Algorithm Process

Requesti = request vector for process Pi If Requesti [j] = k then process Pi wants k instances of resource type Rj 1. If Requesti[i] <= Needi go to step 2 -- Otherwise, raise error condition, since process has exceeded its maximum claim 2. If Requesti <= Available go to step 3 - Otherwise Pi must wait, since resources are not available 3. Pretend to allocate requested resources to Pi by modifying the state as follows: - Available = Available - Requesti; - Allocationi = Allocationi + Requesti; - Needi = Needi - Requesti; 4. If safe -> The resources are allocated to Pi - If unsafe -> Pi must wait, and the old resource-allocation state is restored

Simples/Most Useful Deadlock Avoidance Algorithm

Requires that each process declare the maximum number of resources of each type it may need - Should dynamically examine the resource-allocation state so that a circular-wait condition can never exist

Deadlock Avoidance

Requires that the operating system be given, in advance, additional information concerning which resources a process will request and use during its lifetime. With this information, I can decipher each request whether or not the process should wait - to make this decision the system must consider the resource is currently available, the resource is currently allocated to each process, and the future requests and releases of each process

Events

Resource Acquisition and Release - Resource is going to be either physical or logical

No Preemption Condition

Resources cannot be preempted - A resource can be released only voluntarily by the process holding it, after the process has completed its task

Banker's Algorithm

The deadlock avoidance algorithm used for systems where - Resource types have multiple instances each - Each process must provide a maximum claim - When a process requests a resource it may have to wait - When a process gets all its resources it must return them in a finite amount of time See the example in his notes, as well as that video I watched

Use (Resource Utilization)

The process can operate on the resource and use it for its purposes

Release (Resource Utilization)

The process releases the resource back to the system, so other processes may use it

Request (Resource Utilization)

The process requests the resource; if the request can't be granted immediately, the requesting process waits until it can acquire the resource

Circular Wait Condition

The set of waiting processes must exist such that the first is waiting for a resource held by the second and the second is waiting for a resource held by the third etc. etc. eventually looping back around to the first

Pretending Deadlocks Don't Happen

This is actually the most popular method for OS's, Because in many systems deadlocks occur very rarely such as once per year, and thus it's much cheaper to not employees system at all rather than employing a system that is constantly working but almost never useful - Alternatively the system may just use its manual recovery methods for when there's a program freeze in order to handle deadlocks

Preventing Deadlocks

To implement this solution the system can either use a deadlock prevention or a deadlock avoidance scheme

Resource Utilization

Under the normal mode of operation a process may utilize a resource in the following sequence 1. Request 2. Use 3. Release

Frozen State

When a high priority process on a non-preemptive scheduler runs indefinitely and never returns control to the operating system

Deadlock

When a process never gets the resources it has requested and thus never has the ability to leave the waiting state, because the resources it wants are held by other waiting processes - occurs in multiprogramming environments where processes compete for a finite number of resources