Deadlocks Lots of resources can only be used by one process at a - - PowerPoint PPT Presentation

deadlocks
SMART_READER_LITE
LIVE PREVIEW

Deadlocks Lots of resources can only be used by one process at a - - PowerPoint PPT Presentation

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


slide-1
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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

  • f R0.
slide-26
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
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
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..