Deadlocks Lots of resources can only be used by one process at a time. Exclusive access is needed. Suppose process A needs R1 + R2 and B needs R1 + R2. A gets R1, B gets R2 A waits for R2, B waits for R1 A and B can't continue without second resource and won't give up the one they have --> Deadlock

Deadlocks Processes may be on same machine or distributed over a network. Resources may be hardware or software (files, database). Some resources may be identical (have multiple of same) A preemptable resource can be taken away from a process and given back later with no problem (e.g. Memory) A nonpreemptable resource cannot be taken away without failure (CD, tape).

Deadlocks Nonpreemptable resources are the kind that can cause deadlocks. Processes request a resource, use it, then release it. If the resource is not available the process must wait. Semaphores can be used to manage resources (init to 1) down the semaphore use resource up semaphore

Deadlock-free code Semaphore R1, R2; void A() { down(R1); down(R2); Use(R1,R2); up(R2); up(R1); } void B() { down(R1); down(R2); Use(R1,R2); up(R2); up(R1); }

Code with a possible deadlock Semaphore R1, R2; void A() { down(R1); down(R2); Use(R1,R2); up(R2); up(R1); } void B() { down(R2); down(R1); Use(R1,R2); up(R1); up(R2); }

Deadlocks A set of processes is deadlocked when each process is waiting for a resource to be released by one of the other processes in the set. ABC.... N

4 conditions must hold to have a deadlock 1. Mutual Exclusion. - Process needs exclusive access to resources. 2. Hold and Wait. - Processes can request more resources while not giving any up. 3. No Preemption. - Can't take resources away from a process. 4. Circular wait. Each process is waiting on another process in the group.

4 conditions must hold to have a deadlock If any one of these conditions does not hold a deadlock is not possible. Just make one of them false and there's no deadlock. Any one of the 4. Not easy to do though.

Deadlocks A holds R1 B is requesting R2 A B R1R2 D C R4R3 A cycle in a resource graph shows there is a deadlock.

4 strategies to deal with deadlocks 1. Ignore them. 2. Detect and recover. Let them happen, then do something about it. 3. Avoid by allocating resources carefully. 4. Prevent by making one of the 4 necessary conditions not hold.

The Ostrich Algorithm Pretend there is no problem. Used by Unix and Windows. # of processes, # of files, + virtual mem have limits. Don't worry if a deadlock could happen.

Detection and Recovery Allow deadlocks to happen, then do something to break it up. First consider all resources are unique (one of each type) Use a resource graph and look for cycles -> deadlock Need an algorithm to find cycles For the case of multiple resources of each type use an algorithm that is matrix based.

Detection and Recovery N processes and M resource classes E = Existing resource vector [E1, E2,.., Em] A = Available resource vector [A1, A2,.. Am] C = Current allocation matrix (what processes currently have) C11 C C1m C21 C C2m. Cn1 Cn Cnm

Detection and Recovery R = Request matrix (what processes need) R11 R R1m R21 R R2m. Rn1 Rn Rnm The algorithm compares vectors (A <= B means each element of A is <= to that position in B) Ai <= Bi, 1<=i <=m

Detection and Recovery Each process starts off unmarked. The algorithm will mark processes that are not deadlocked. At end unmarked processes are deadlocked. 1. look for an unmarked process where its row in R is <= A. 2. If process is found mark it and add its row from C to A. 3. Otherwise algorithm ends. Unmarked processes are deadlocked.

Detection and Recovery How often should that algorithm run? At every resource request? Works, but expensive. Or every few minutes or when cpu load is low – maybe processes can't run so load is low. Other ideas?

How to recover once deadlock is found? Preeemption – take a resource away and give to another. Depends on resource if it will work or not. May need manual intervention. Rollback – Checkpoint processes (save state so can be restarted there later) Then can rollback to that point if needed. Kill Processes – until no more deadlock.

Deadlock Avoidance Usually resources are requested one at a time rather than all at once. Avoid deadlocks by carefully allocating resources and only allocate them if a deadlock cannot result. Safe states are states where a deadlock does not have to happen – there is some sequence where all the processes can run to completion. An unsafe state is a state where a deadlock may happen.

Banker's Algorithm Deadlock avoidance algorithm that comes from Dijkstra. Works in the way a banker gives lines of credit to customers. It checks to see if a request would lead to an unsafe state. If so, the request is denied. Processes have a maximum claim for each resource.

Banker's Algorithm Safe: Unsafe: Free = 2 Free = 1 Uses C, R, E and A from before + P = Possessed resources (E - A)

Banker's Algorithm Algorithm for checking safety of a state: 1. Find a process from R that can have all its requests (max) filled. 2. Assume that process runs to completion. Add its resources to A. 3. Repeat 1 and 2 until all processes can run to completion (safe) or a deadlock happens (unsafe).

Banker's Algorithm Example E = [ 8, 5, 9, 7 ], A = [ 1, 2, 2, 2 ] Claim Matrix Allocation Matrix Is this a safe or unsafe state?

Banker's Algorithm Example P2 could exercise its maximum claim and release the resources causing A = [ 5, 2, 2, 5] P4 could exercise its maximum claim and release the resources causing A = [ 6, 2, 5, 5]. Then any of the other processes could exercise its maximum claim. Therefore, the state is safe.

Banker's Algorithm Example A = [ 0, 2, 2, 2 ] Allocation Matrix What if we try to give P3 one R0? Is that safe?

Banker's Algorithm Example What if we try to give P3 one R0? Is that safe? No! There is no process that can have its maximum claim exercised. Therefore, the banker's algorithm, would say to not give P3 that unit of R0.

Banker's Algorithm The Banker's algorithm is nice and all. It is much studied. But it isn't practical as the maximum claim of processes is dynamic and not known in advanced. Never used in practice.

Deadlock Prevention Make one of the four necessary conditions not hold. - Mutual Exclusion - cannot be done away with totally use it only when needed. - Hold and Wait - request all resources together at beginning. May not know what will be needed. Not optimal use of resources. - release all held resources when requesting another.

Deadlock Prevention - No Preemption - Difficult to make false on many resources. - Circular wait - Only let process have one resource at a time – not realistic. - Number resources. Make requests in numerical order. Will not have cycles in resource allocation graph..