SLIDE 1 Deadlocks
Lots of resources can only be used by
- ne 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
SLIDE 2
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).
SLIDE 3
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
SLIDE 4
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); }
SLIDE 5
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); }
SLIDE 6 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. A B C
....
N
SLIDE 7 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
- n another process in the group.
SLIDE 8
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.
SLIDE 9
Deadlocks
A holds R1 B is requesting R2
A
B
R1 R2 D C R4 R3
A cycle in a resource graph shows there is a deadlock.
SLIDE 10 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.
SLIDE 11
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.
SLIDE 12
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.
SLIDE 13
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 C12 .......................................C1m C21 C22 ........................................C2m . . . Cn1 Cn2 ........................................Cnm
SLIDE 14
Detection and Recovery
R = Request matrix (what processes need)
R11 R12 .......................................R1m R21 R22 ........................................R2m . . . Rn1 Rn2 ........................................Rnm
The algorithm compares vectors (A <= B means each element of A is <= to that position in B) Ai <= Bi, 1<=i <=m
SLIDE 15 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.
SLIDE 16 Detection and Recovery
How often should that algorithm run? At every resource request? Works, but expensive. Or every few minutes
- r when cpu load is low – maybe
processes can't run so load is low. Other ideas?
SLIDE 17
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.
SLIDE 18
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.
SLIDE 19
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.
SLIDE 20
Banker's Algorithm
Safe: Unsafe: Free = 2 Free = 1
Has Max
A 1 6 B 1 5 C 2 4 D 4 7
Has Max
A 1 6 B 2 5 C 2 4 D 4 7
Uses C, R, E and A from before + P = Possessed resources (E - A)
SLIDE 21 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).
SLIDE 22
Banker's Algorithm Example
E = [ 8, 5, 9, 7 ], A = [ 1, 2, 2, 2 ]
R R0 R1 R2 R3 P0 3 2 1 4 P1 2 5 2 P2 5 1 5 P3 1 5 3 P4 3 3 3 C R0 R1 R2 R3 P0 2 1 1 P1 1 2 1 P2 4 3 P3 2 1 P4 1 3
Claim Matrix Allocation Matrix
Is this a safe or unsafe state?
SLIDE 23
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.
SLIDE 24
Banker's Algorithm Example
A = [ 0, 2, 2, 2 ]
C R0 R1 R2 R3 P0 2 1 1 P1 1 2 1 P2 4 3 P3 1 2 1 P4 1 3
Allocation Matrix
What if we try to give P3 one R0? Is that safe?
SLIDE 25 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
SLIDE 26
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.
SLIDE 27 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.
SLIDE 28 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..