CENG 334 Operating Systems 04 Deadlocks Asst Prof

CENG 334 – Operating Systems 04 - Deadlocks Asst. Prof. Yusuf Sahillioğlu Computer Eng. Dept, , Turkey

Outline 2 / 51 ü ü ü ü The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection Recovery from Deadlock

Definition & Examples 3 / 51 ü Deadlock: A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set. ü Example: ü System has 2 disk drives: R 1 & R 2. ü P 1 and P 2 each holds one disk drive and each needs another one. ü Example: ü semaphores A and B, initialized to 1. (not always: depends on CS). P 0 P 1 wait(A); //context-switch (CS) wait(B); wait(A);

Definition & Examples 4 / 51 ü Deadlock: A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set.

Definition & Examples 5 / 51 ü Deadlock: A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set.

Definition & Examples 6 / 51 ü Deadlock: A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set. ü Traffic only in one direction. ü If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback). ü Several cars may have to be backed up if a deadlock occurs. ü Starvation is possible. ü Note: Most OSes do not prevent or deal with deadlocks. It’s app. programmer’s duty (kill, reboot, . . ). section 1 section 2

Conditions 7 / 51 ü Deadlocks can arise if 4 conditions hold simulataneously: ü Mutual exclusion: only one process at a time can use a resource (another process P 2 cannot access while P 1 is using). ü Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes ü No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task ü Circular wait: there exists a set {P 0, P 1, …, Pn} 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, …, Pn– 1 is waiting for a resource that is held by Pn, and Pn is waiting for a resource that is held by P 0.

Solutions 8 / 51 ü Current OSes do not deal with deadlocks. ü Some solutions that might be implemented in future OSes. ü System model. ü Resource types R 1, R 2, . . . , Rm ü CPU cycles, memory space, I/O devices (scanners). ü Each resource type Ri has Wi instances. ü Each process utilizes a resource as follows: ü request (may cause the process to wait); e. g. fopen() -> open() ü use ü Release; e. g. fclose() -> close()

Deadlock Representation 9 / 51 ü Use resource-allocation graph: A set of vertices V & edges E. ü V is partitioned into two types: ü P = {P 1, P 2, …, Pn}, the set consisting of all the processes in the system ü R = {R 1, R 2, …, Rm}, the set consisting of all resource types in the system ü request edge: directed edge Pi Rj //Pi is waiting for Rj ü assignment edge: directed edge Rj Pi

Deadlock Representation 10 / 51 ü Process ü Resource Type with 4 instances ü Pi requests instance of Rj Pi Rj ü Pi is holding an instance of Rj Pi Rj

Deadlock Representation 11 / 51 ü Example of a resource-allocation graph at time t:

Deadlock Representation 12 / 51 ü Example of a resource-allocation graph with a deadlock:

Deadlock Representation 13 / 51 ü Example of a resource-allocation graph with a deadlock: ü All resources are held by waiting processes. Since the waiting processes will not run they will not release the resources deadlock!

Deadlock Representation 14 / 51 ü Graph with a cycle but no deadlock:

Deadlock Representation 15 / 51 ü Graph with a cycle but no deadlock: ü P 2 & P 4, which are not in waiting mode, will release their resources.

Deadlock Representation 16 / 51 ü Basic conclusions on resource-alloc graphs: ü If graph contains no cycles no deadlock ü If graph contains a cycle: ü if only one instance per resource type, then deadlock ü if several instances per resource type, possibility of deadlock ü So resource-alloc graph is useful for deadlock detection

Deadlock Handling 17 / 51 ü Deadlock prevention/avoidance ü Deadlock detection needed ü Ignore the problem and pretend that deadlocks never occur in the system ü Used by most operating systems, including UNIX ü No deadlock handling in kernel ‘cos detecting/preventing/avoiding is costly: admin/user stops/restarts processes.

Deadlock Prevention vs. Avoidance 18 / 51 ü Prevention: ensure at least 1 of the 4 conditions is false. ü Avoidance: ensure system is never in unsafe state where deadlock is possible, e. g. , Banker’s algorithm.

Deadlock Prevention 19 / 51 ü Basic principle: restrict the ways requests can be made ü If 1 of the 4 simulataneous conditions FALSE, then no deadlock. ü Try to negate one of those 4. ü Mutual Exclusion: if all resources are sharable, many processes can access them whenever they want. ü Convert non-sharable -> sharable: spooling sw for printers. ü Hold and Wait: must guarantee that whenever a process requests a resource, it does not hold any other resources ü Require process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none ü Low resource utilization; starvation possible

Deadlock Prevention 20 / 51 ü Basic principle: restrict the ways requests can be made ü If 1 of the 4 simulataneous conditions FALSE, then no deadlock. ü Try to negate one of those 4. ü No Preemption ü If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released ü Preempted resources are added to the list of resources for which the process is waiting ü Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting ü Circular Wait: impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration: if I request resrc 5, next time I cannot req 4, but 6 or 9.

Deadlock Avoidance 21 / 51 ü Basic principle: use a priori info to avoid deadlocks. ü A priori info: each process declares the max number of resources of each type that it may need. ü Start at safe state; traverse at that space; avoid unsafe states.

Deadlock Avoidance Algorithms 22 / 51 ü Two types: ü Single instance for each resource type. ü Use the resource-allocation graph. ü Multiple instances for each resource type. ü Use Banker’s Algorithm.

Deadlock Avoidance Algorithms 23 / 51 ü Single instance for each resource type. ü Besides request edge and allocation edge, we add claim edge. ü Claim edge Pi Rj indicated that process Pi may request resource Rj; represented by a dashed line. ü Claim edge converts to request edge when a process requests a resource. ü Request edge converted to an assignment edge when the resource is allocated to the process. ü When a resource is released by a process, assignment edge reconverts to a claim edge ü Resources must be claimed a priori in the system

Deadlock Avoidance Algorithms 24 / 51 ü Single instance for each resource type.

Deadlock Avoidance Algorithms 25 / 51 ü Single instance for each resource type. ü P 2 requests R 2; should we allocate?

Deadlock Avoidance Algorithms 26 / 51 ü Single instance for each resource type. ü If allocation is done, request edge’ll be converted to assignment edge. ü This new state has a cycle (unsafe state); so avoid that allocation. ü Although there’s no deadlock now, there may be a deadlock: unsafe.

Deadlock Avoidance Algorithms 27 / 51 ü Multiple instances for each resource type. ü Banker’s Algorithm. ü Each process must a priori claim maximum use. ü 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.

Deadlock Avoidance Algorithms 28 / 51 ü Data structures for the Banker’s Algo. ü Let n = number of processes, and m = number of resources types. ü Available: Vector of length m. If available [j] = k, there are k instances of resource type Rj available at that time ü Max: n x m matrix. If Max[i, j] = k, then process Pi may request at most k instances of resource type Rj ü Allocation: n x m matrix. If Allocation[i, j] = k then Pi is currently allocated k instances of 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]

Deadlock Avoidance Algorithms 29 / 51 ü Data structures for the Banker’s Algo. ü Available: initially decided by your hw configuration. ü Max: initially declared by process. ü Allocation: initially all 0 s. ü Need: initially same as Max.

Deadlock Avoidance Algorithms 30 / 51 ü ü 5 processes: P 0 through P 4; 3 resource types: A (10 instances), B (5 instances), and C (7 instances) Existing vector: [10 5 7] Available[j] = Existing[j] – Allocation[i, j] ü Snapshot at time t: ü Allocation ABC P 0 010 P 1 200 P 2 302 P 3 211 P 4 002 Max ABC 753 322 902 222 433 Need ABC 743 122 600 011 431 Available ABC 332

Deadlock Avoidance Algorithms 31 / 51 ü Some notation for the algo. ü X X is a matrix. ABC X_i is the ith row of the matrix; it is a vector: X_3 = [2 1 1]. 010 200 302 211 002 ü V ABC 332 V is a vector; V = [3 3 2]. Compare Xi vs. V V == X_i V <= X_i //all elmnts <= V >= X_i //all elements

Deadlock Avoidance Algorithms 32 / 51 ü Safety-check algorithm: check whether a given state is safe or not? ü 1. Let Work and Finish be vectors of length m and n, respectively. Initialize: ü Work = Available ü Finish [i] = false for i = 0, 1, …, n- 1 ü 2. Find an i such that both: ü (a) Finish [i] = false ü (b) Need_i <= Work ü If no such i exists, go to step 4 ü 3. Work = Work + Allocation_i Finish[i] = true go to step 2 ü 4. If Finish [i] == true for all i, then the system is in a safe state

Deadlock Avoidance Algorithms 33 / 51 ü Do the safety-check when a process makes a request. ü Request = request vector for process Pi. If Request_i[j] = k then process Pi wants k instances of resource type Rj: [0 2 0] requests 2 more B. ü 1. If Request_i <= Need_i go to step 2. Otherwise, raise error condition, since process has exceeded its maximum claim in the begin ü 2. If Request_i <= 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 – Request; Allocation_i = Allocation_i + Request_i; Need_i = Need_i – Request_i; If safe: the resources are allocated to Pi If unsafe: Pi must wait, and the old resorce-alloction state is restored

Deadlock Avoidance Algorithms 34 / 51 ü ü ü 5 processes: P 0 through P 4 3 resource types: A (10 instances), B (5 instances), and C (7 instances) Existing vector: [10 5 7] Initially Allocation=[0] and Available = Existing Assume processes declared their max demands as follows in the begin P 0 P 1 P 2 P 3 P 4 Max ABC 753 322 902 222 433

Deadlock Avoidance Algorithms 35 / 51 ü Assume later on we have the following system state ü Existing = [10 5 7] ü Max Allocation ABC P 0 753 010 P 1 322 200 P 2 902 302 P 3 222 211 P 4 433 002

Deadlock Avoidance Algorithms 36 / 51 ü Assume later on we have the following system state ü Existing = [10 5 7] ü We can derive Need = Max – Allocation ü Max Allocation Need ABC ABC P 0 753 010 743 P 1 322 200 122 P 2 902 302 600 P 3 222 211 011 P 4 433 002 431

Deadlock Avoidance Algorithms 37 / 51 ü Assume later on we have the following system state ü Existing = [10 5 7] ü We can derive Available[j] = Existing[j] – Allocation[i, j] ü Max Allocation Need Available ABC ABC 332 P 0 753 010 743 P 1 322 200 122 P 2 902 302 600 P 3 222 211 011 P 4 433 002 431

Deadlock Avoidance Algorithms 38 / 51 ü Assume later on we have the following system state ü Existing = [10 5 7] ü Is this a safe state? ü Max Allocation Need Available ABC ABC 332 P 0 753 010 743 P 1 322 200 122 P 2 902 302 600 P 3 222 211 011 P 4 433 002 431 ü Answer: yes. ü Why? Find Need_i that is <= Available; do your thing. Seq: P 1 -3 -4 -2 -0

Deadlock Avoidance Algorithms 39 / 51 ü Assume P 1 requests [1 0 2] at a time when Available = [3 3 2] ü First check [1 0 2] <= [3 3 2] ü Pretend we grant and check the new state for safety ü Max Allocation Need Available ABC ABC 230 P 0 753 010 743 P 1 322 302 020 P 2 902 302 600 P 3 222 211 011 P 4 433 002 431 ü This state is safe ‘cos P 1 is run and terminates and Available = [5 3 2]. Then P 3 is done and Available = [7 4 3], and so on. Seq: P 1 -3 -4 -0 -2 ü We grant the request and give [1 0 2] to P 1

Deadlock Avoidance Algorithms 40 / 51 ü Assume P 4 requests [3 3 0] at a time when Available = [2 3 0] ü First check [3 3 0] <= [3 3 2] fails; do not grant the request ü Why Available = [2 3 0] now?

Deadlock Avoidance Algorithms 41 / 51 ü Assume P 0 requests [0 2 0] at a time when Available = [2 3 0] ü First check [0 2 0] <= [2 3 0] ü Pretend we grant and check the new state for safety ü Max Allocation Need Available ABC ABC 210 P 0 753 030 723 P 1 322 302 020 P 2 902 302 600 P 3 222 211 011 P 4 433 002 431 ü This state is not safe ‘cos after checking Need_i we see that no process can run and terminate w/ Available = [2 1 0]. ü Don’t grant the request to P 0 to avoid unsafe state; P 0 is blocked.

Deadlock Detection 42 / 51 ü Allow system to enter deadlock state (unlike Deadlock avoidance) ü Detection algorithm ü Recovery scheme //simplest way: kill process(es) in the deadlock

Deadlock Detection 43 / 51 ü Two types: ü Single instance for each resource type. ü Use the resource-allocation graph. ü Multiple instances for each resource type. ü Use something similar to Banker’s Algorithm.

Deadlock Detection 44 / 51 ü Single instance for each resource type. ü Maintain 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

Deadlock Detection 45 / 51 ü Single instance for each resource type. Resource-allocation graph Corresponding wait-for graph 1+ cycles here: deadlock detected!

Deadlock Detection 46 / 51 ü A dead simple cycle detection algorithm (O(n), n = # vertices). ü Graph G has a cycle iff DFS on G has a back edge. ü Back edge (u, v) connects u to an ancestor v in a depth-first tree.

Deadlock Detection 47 / 51 ü ü A dead simple cycle detection algorithm (O(n), n = # vertices). Graph G has a cycle iff DFS on G has a back edge. Proof: just for fun. Left direction: if DFS(G) has a back edge, then G has a cycle. ü Right direction: if G has a cycle, then DFS(G) has a back edge. ü Assume v 0 is the 1 st vertex in the cycle visited by DFS. Claim: (vk, v 0) is a back edge. v 1 visited before we finish visiting v 0. similarly vi …. vi-1; and vk … v 0. So we definitely consider (vk, v 0) between start vk and finish vk, and when considered it’ll be a back edge ‘cos ancestor v 0 is currently in process (in the recursion).

Deadlock Detection 48 / 51 ü Multiple instances for each resource type. ü 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. ü No need for a Max matrix to be declared by the processes in the beginning (easier).

Deadlock Detection 49 / 51 ü 1. Let Work and Finish be vectors of length m and n, respectively Initialize: ü (a) Work = Available ü (b) For i = 1, 2, …, n, if Allocation_i != 0, then Finish[i] = false; otherwise, Finish[i] = true ü 2. Find an index i such that both: ü (a) Finish[i] == false ü (b) Request_i <= Work ü If no such i exists, go to step 4 ü 3. Work = Work + Allocation_i ü Finish[i] = true ü Go to step 2 ü 4. If Finish[i] == false, for some i, 1 <= i <= n, then the system is in deadlock state. Moreover, if Finish[i] == false, then Pi is deadlocked

Deadlock Detection 50 / 51 ü An example: Five processes P 0 through P 4; three resource types A (7 instances), B (2 instances), and C (6 instances). Existing = [7 2 6] ü Snapshot at time t: P 0 P 1 P 2 P 3 P 4 Allocation ABC 010 200 303 211 002 Request ABC 000 202 000 100 002 Available ABC 000 ü Trigger deadlock detection algorithm ü Sequence <P 0, P 2, P 3, P 1, P 4> will result in Finish[i] = true for all i

Deadlock Detection 51 / 51 ü Assume P 2 makes a request [0 0 1] ü Snapshot at time t 2: P 0 P 1 P 2 P 3 P 4 Allocation ABC 010 200 303 211 002 Request ABC 000 202 001 100 002 Available ABC 000 ü P 0 runs and terminates and Available = [0 1 0], which cannot satisfy any other process requests: Deadlock detected.

Deadlock Detection 52 / 51 ü Detection algorithm usage ü When, and how often, to invoke depends on: ü How often a deadlock is likely to occur? ü How many processes will need to be rolled back? ü one for each disjoint cycle