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

(1)

Chapter 7 Deadlocks

Deadlocks

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

A System Model

Competing processes – distributed?

Resources:

Physical Resources, e.g., CPU, printers, memory, etc.

Logical Resources, e.g., files, semaphores, etc.

(2)

Deadlocks

A Normal Sequence

1. Request: Granted or Rejected 2. Use

3. Release

Remarks

No request should exceed the system capacity!

Deadlock can involve different resource types!

Several instances of the same type!

Deadlocks

void *do_work_one(void *param) { pthread_mutex_lock(&first_mutex);

pthread_mutex_lock(&second_mutex);

/* Do some work */

pthread_mutex_unlock(&second_mutex);

pthread_mutex_unlock(&first_mutex);

pthread_exit(0); }

void *do_work_two(void *param) {

pthread_mutex_lock(&second_mutex);

pthread_mutex_lock(&first_mutex);

/* Do some work */

pthread_mutex_unlock(&first_mutex);

pthread_mutex_unlock(&second_mutex);

pthread_exit(0); }

…

Pthread_mutex_init(&first_mutex, NULL);

Pthread_mutex_init(&second_mutex, NULL);

(3)

Deadlock Characterization

Necessary Conditions

1. Mutual Exclusion – At least one resource must be held in a non- sharable mode!

2. Hold and Wait – Pi is holding at least one resource and waiting to acquire additional resources that are currently held by other processes!

(deadlock Æ conditions or ¬ conditions Æ ¬ deadlock)

Deadlock Characterization

3. No Preemption – Resources are nonpreemptible!

4. Circular Wait – There exists a set {P

₀

, P

₁

, …, P

_n

} of waiting process such that P

₀

P

₁

, P

₁

P

₂

, …, P

_n-1

P

_n

, and P

_n

P

₀

.

Remark:

Condition 4 implies Condition 2.

The four conditions are not completely independent!

wait

wait wait

wait

(4)

Resource Allocation Graph

P1 P2 P3

R1 R3

R2 R4

Vertices

Processes:

{P1,…, Pn}

Resource Type : {R1,…, Rm}

Edges

Request Edge:

Pi Æ Rj Assignment Edge:

Ri Æ Pj System Resource-Allocation Graph

Resource Allocation Graph

Example

No-Deadlock

Vertices

P = { P1, P2, P3 }

R = { R1, R2, R3, R4 }

Edges

E = { P1ÆR1, P2ÆR3, R1ÆP2, R2ÆP2, R2ÆP1, R3ÆP3 }

Resources

R1:1, R2:2, R3:1, R4:3

Æ results in a deadlock.

P1 P2 P3

R1 R3

R2 R4

(5)

Resource Allocation Graph

Observation

The existence of a cycle

One Instance per Resource Type Æ Yes!!

Otherwise Æ Only A Necessary Condition!!

P1

P2

P3

P4 R1

R2

Methods for Handling Deadlocks

Solutions:

1. Make sure that the system never enters a deadlock state!

Deadlock Prevention: Fail at least one of the necessary conditions

Deadlock Avoidance: Processes provide information regarding their resource usage. Make sure that the system always stays at a “safe” state!

(6)

Methods for Handling Deadlocks

2. Do recovery if the system is deadlocked.

Deadlock Detection

Recovery

3. Ignore the possibility of deadlock occurrences!

Restart the system “manually” if the system “seems” to be deadlocked or stops functioning.

Note that the system may be “frozen”

temporarily!

Deadlock Prevention

Observation:

Try to fail anyone of the necessary condition!

∵ ¬ (∧ i-th condition) → ¬ deadlock

Mutual Exclusion

?? Some resources, such as a printer,

are intrinsically non-sharable??

(7)

Deadlock Prevention

Hold and Wait

Acquire all needed resources before its execution.

Release allocated resources before request additional resources!

Disadvantage:

Low Resource Utilization

Starvation

Tape Drive & Disk Disk & Printer Hold Them All

[ Tape Drive Æ Disk ] [ Disk & Printer ]

Deadlock Prevention

No Preemption

Resource preemption causes the release of resources.

Related protocols are only applied to resources whose states can be saved and restored, e.g., CPU register &

memory space, instead of printers or tape drives.

Approach 1:

Resource Request

Allocated resources are released Satisfied?

granted

No

Yes

(8)

Deadlock Prevention

Approach 2

Resource

Request Satisfied?

No

Yes

Requested Resources are held by “Waiting”

processes?

Preempt those Resources.

Yes

No

“Wait” and its allocated resources may be preempted.

granted

Deadlock Prevention

Circular Wait

A resource-ordering approach:

Type 1 – strictly increasing order of resource requests.

Initially, order any # of instances of Ri

Following requests of any # of instances of Rj must satisfy F(Rj) > F(Ri), and so on.

* A single request must be issued for all needed instances of the same resources.

F : R Æ N

Resource requests must be made in an increasing order of enumeration.

(9)

Deadlock Prevention

Type 2

Processes must release all Ri’s when they request any instance of Rj if F(Ri) ≥ F(Rj)

F : R Æ N must be defined according to the normal order of resource usages in a system, e.g.,

F(tape drive) = 1 F(disk drive) = 5 F(printer) = 12

?? feasible ??

Deadlock Avoidance

Motivation:

Deadlock-prevention algorithms can cause low device utilization and reduced system throughput!

Î Acquire additional information about how resources are to be requested and have better resource allocation!

Processes declare their maximum

number of resources of each type that it

may need.

(10)

Deadlock Avoidance

A Simple Model

A resource-allocation state

<# of available resources,

# of allocated resources,

max demands of processes>

A deadlock-avoidance algorithm dynamically examines the resource-allocation state and make sure that it is safe.

e.g., the system never satisfies the circular- wait condition.

Deadlock Avoidance

Safe Sequence

A sequence of processes <P1, P2, …, Pn> is a safe sequence if

Safe State

The existence of a safe sequence

Unsafe

∑

<

+

≤

∀

i j

Pj allocated

Available Pi

need

Pi , ( ) ( )

safe unsafe

deadlock

Deadlocks are avoided if the system can allocate resources to each process up to its maximum request in some order. If so, the system is in a safe state!

(11)

Deadlock Avoidance

Example:

2 9

P2

2 4

P1

3 5

10 P0

Available Allocated

max needs

• The existence of a safe sequence <P1, P0, P2>.

• If P2 got one more, the system state is unsafe.

How to ensure that the system will always remain in a safe state?

)) 2 , (

), 3 , 2 ( ), 2 , 1 ( ), 5 , 0

((P P P available

Q

P1 P2

R1

R2

•Request Edge

Pi Rj

•Assignment Edge

•Claim Edge

resource allocated

resource release

request made

Deadlock Avoidance – Resource- Allocation Graph Algorithm

One Instance per Resource Type

(12)

Deadlock Avoidance – Resource- Allocation Graph Algorithm

P1 P2

R1

R2

A cycle is detected!

Î The system state is unsafe!

• R2 was requested & granted!

Safe state: no cycle Unsafe state: otherwise

Cycle detection can be done in O(n²)

Deadlock Avoidance – Banker’s Algorithm

Available [m]

If Available [i] = k, there are k instances of resource type Ri available.

Max [n,m]

If Max [i,j] = k, process Pi may request at most k instances of resource type Rj.

Allocation [n,m]

If Allocation [i,j] = k, process Pi is currently allocated k instances of resource type Rj.

Need [n,m]

If Need [i,j] = k, process Pi may need k more instances of resource type Rj.

¾ Need [i,j] = Max [i,j] – Allocation [i,j]

n: # of

processes, m: # of resource types

(13)

Deadlock Avoidance – Banker’s Algorithm

Safety Algorithm – A state is safe??

1. Work := Available & Finish [i] := F, 1≦ i≦ n 2. Find an i such that both

1. Finish [i] =F 2. Need[i] ≦ Work

If no such i exist, then goto Step4 3. Work := Work + Allocation[i]

Finish [i] := T; Goto Step2

4. If Finish [i] = T for all i, then the system is in a safe state.

Where Allocation[i] and Need[i] are the i-th row of Allocation and Need, respectively, and

X≦ Y if X[i] ≦ Y[i] for all i, X < Y if X ≦ Y and Y≠ X

n: # of

1. If Request_i ≦ Need_i, then Goto Step2; otherwise, Trap 2. If Request_i ≦ Available, then Goto Step3; otherwise, Pi

must wait.

3. Have the system pretend to have allocated resources to process P_i by setting

Available := Available – Request_i; Allocation_i := Allocation_i + Request_i; Need_i := Need_i – Request_i;

Execute “Safety Algorithm”. If the system state is safe, the request is granted; otherwise, Pi must wait, and the old resource-allocation state is restored!

Deadlock Avoidance – Banker’s Algorithm

Resource-Request Algorithm

Request_i [j] =k: P_i requests k instance of resource type Rj

(14)

1 3 4 3 3 4 2 0 0 P4

1 1 0 2 2 2 1 1 2 P3

0 0 6 2 0 9 2 0 3 P2

2 2 1 2 2 3 0 0 2 P1

2 3 3 3 4 7 3 5 7 0 1 0 P0

C B A C B A C B A C B A

Available Need

Max Allocation

• A safe state

∵ <P1,P3,P4,P2,P0> is a safe sequence.

Deadlock Avoidance

An Example

Deadlock Avoidance

1 3 4 2 0 0 P4

1 1 0 1 1 2 P3

0 0 6 2 0 3 P2

0 2 0 2 0 3 P1

0 3 2 3 4 7 0 1 0 P0

C B A C B A C B A

Available Need

Allocation

Let P1 make a request Requesti = (1,0,2) Request_i ≦ Available ((1,0,2) ≦ (3,3,2))

• If Request4 = (3,3,0) is asked later, it must be rejected.

• Request0 = (0,2,0) must be rejected because it results in an unsafe state.

Æ Safe ∵ <P1,P3,P4,P0,P2> is a safe sequence!

(15)

Deadlock Detection

Motivation:

Have high resource utilization and

“maybe” a lower possibility of deadlock occurrence.

Overheads:

Cost of information maintenance

Cost of executing a detection algorithm

Potential loss inherent from a deadlock recovery

Deadlock Detection – ^Single

Instance per Resource Type

P1 P2

P5

P4

P3

R5 R2

R4 R3

R1

P2

P1 P3

P4 P5

A Resource-Allocation Graph A Wait-For Graph

Pi Rq Pj Pi Pj

• Detect an cycle in O(n²).

• The system needs to maintain the wait-for graph

(16)

Deadlock Detection – ^Multiple

Instance per Resource Type

Data Structures

Available[1..m]: # of available resource instances

Allocation[1..n, 1..m]: current resource allocation to each process

Request[1..n, 1..m]: the current request of each process

If Request[i,j] = k, Pi requests k more instances of resource type Rj

n: # of

Deadlock Detection – Multiple Instance per Resource Type

1. Work := Available. For i = 1, 2, …, n, if Allocation[i] ≠ 0, then Finish[i] = F;

otherwise, Finish[i] =T.

2. Find an i such that both a. Finish[i] = F

b. Request[i] ≦ Work If no such i, Goto Step 4 3. Work := Work + Allocation[i]

Finish[i] := T Goto Step 2

4. If Finish[i] = F for some i, then the system is in a deadlock state. If Finish[i] = F, then process Pi is deadlocked.

Complexity = O(m * n²)

(17)

2 0 0 2 0 0 P4

0 0 1 1 1 2 P3

0 0 0 3 0 3 P2

2 0 2 0 0 2 P1

0 2 0 0 0 0 0 1 0 P0

C B A C B A C B A

Available Request

Allocation

Î Find a sequence <P0, P2, P3, P1, P4> such that Finish[i]

= T for all i.

If Request2 = (0,0,1) is issued, then P1, P2, P3, and P4 are deadlocked.

Deadlock Detection – ^Multiple

Instances per Resource Type

An Example

Deadlock Detection – Algorithm Usage

When should we invoke the detection algorithm?

How often is a deadlock likely to occur?

How many processes will be affected by a deadlock?

Time for Deadlock Detection?

CPU Threshold? Detection Frequency? … Every

rejected request

＋ overheads－

∞

－ processes affected＋

(18)

Deadlock Recovery

Whose responsibility to deal with deadlocks?

Operator deals with the deadlock manually.

The system recover from the deadlock automatically.

Possible Solutions

Abort one or more processes to break the circular wait.

Preempt some resources from one or more deadlocked processes.

Deadlock Recovery – Process Termination

Process Termination

Abort all deadlocked processes!

Simple but costly!

Abort one process at a time until the deadlock cycle is broken!

Overheads for running the detection again and again.

The difficulty in selecting a victim!

But, can we abort any process?

Should we compensate any damage caused by aborting?

(19)

Deadlock Recovery – Process Termination

What should be considered in choosing a victim?

Process priority

The CPU time consumed and to be consumed by a process.

The numbers and types of resources used and needed by a process

Process’s characteristics such as

“interactive or batch”

The number of processes needed to be aborted.

Deadlock Recovery – Resource Preemption

Goal: Preempt some resources from processes and give them to other processes until the

deadlock cycle is broken!

Issues

Selecting a victim:

It must be cost-effective!

Roll-Back

How far should we roll back a process whose resources were preempted?

Starvation

Will we keep picking up the same process as a victim?

How to control the # of rollbacks per process efficiently?

(20)

Deadlock Recovery – Combined Approaches

Partition resources into classes that are hierarchically ordered.

⇒ No deadlock involves more than one class

Handle deadlocks in each class independently

Deadlock Recovery – Combined Approaches

Examples:

Internal Resources: Resources used by the system, e.g., PCB

→ Prevention through resource ordering

Central Memory: User Memory

→ Prevention through resource preemption

Job Resources: Assignable devices and files

→ Avoidance

∵

This info may be obtained!

Swappable Space: Space for each user process on the backing store

→ Pre-allocation ∵ the maximum need is known!

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

Chapter 7 Deadlocks

Deadlocks