Chapter 10 deadlock
Download
1 / 78

Chapter 10: Deadlock - PowerPoint PPT Presentation


  • 60 Views
  • Uploaded on

Chapter 10: Deadlock. Prof. Steven A. Demurjian, Sr. † Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155. [email protected] http://www.engr.uconn.edu/~steve (860) 486 - 4818.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Chapter 10: Deadlock' - elroy


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Chapter 10 deadlock
Chapter 10: Deadlock

Prof. Steven A. Demurjian, Sr. †

Computer Science & Engineering Department

The University of Connecticut

191 Auditorium Road, Box U-155

Storrs, CT 06269-3155

[email protected]

http://www.engr.uconn.edu/~steve

(860) 486 - 4818

† These slides have been modified from a

set of originals by Dr. Gary Nutt.


Purpose of this chapter
Purpose of this Chapter

  • What is Deadlock?

    • General Problem

    • Deadlock/Concurrency Control in Databases

  • What are Strategies for Handling Deadlock?

    • Prevention

    • Avoidance

    • Detection and Recovery

  • What are Formal Models Used by OS to Handle Deadlock?

  • Why are Formal Models Needed?

  • Focus on Avoidance & Detection and Recovery


General problem a deadly embrace
General Problem: A Deadly Embrace

Process 3

Resource 3

Process 1

Process 2

Resource 1

Resource 2


Deadlock in databases
Deadlock in Databases

Transaction 1

Transaction 2

Transaction 3

Shared

Database

  • Databases Must Control Access to Information by Multiple Concurrent Transactions (Processes)

  • How do we Prevent Simultaneous Updates of Database by Concurrent Transactions (Processes)?

  • Data is the Resource in Database System


Addressing deadlock
Addressing Deadlock

  • Deadlock is Global Condition!

  • Need to Analyze All Processes that Need All Resources

  • Can’t Make Local Decision Based on Needs of One Process

  • Four Deadlock Approaches:

    • Prevention: Never Allow Deadlock to Occur

    • Avoidance: System Makes Decision to Head Off Future Deadlock State

    • Detection & Recovery: Check for Deadlock (Periodically or Sporadically), Then Recover

    • Manual Intervention: Operator Reboot if System Seems Too Slow


Prevention a first look
Prevention: A First Look

  • Design the System So that Deadlock is Impossible

  • Deadlock Only Occurs If All Following TRUE!!

    • Mutual Exclusion: Allocated Resources are Exclusive Property of Process

    • Hold and Wait: Process Can Hold Resource While Waiting for Another Resource

    • Circular Waiting: Classic Example in Slide 10.3

    • No Preemption: Only Process Can Release Resources or Withdraw Resource Request

  • All Four Necessary for Deadlock to Exist

  • Prevention Requires Resource Manager to Violate at Least One Condition at All Times!


Avoidance a first look
Avoidance: A First Look

  • Construct a Formal Model of System States

  • Via Model, Choose a Strategy that Will Not Allow the System to Go to a Deadlock State

  • Predictive Approach: Requires Processes to Declare Intent re. Resources in Advance

    • Process X Needs 3 of A, 2 of B, 0 of C, 4 of D

    • Represents “Maximum Claim” on Resources

    • Process X Won’t Proceed Until all Resources Available

    • May Require “Long” Waits

  • Amenable to Formal Solution/Algorithm


Detection and recovery a first look
Detection and Recovery: A First Look

  • When Deadlock Occurs, Can we Detect and Recover?

  • Two Phases to Algorithm

    • Detection: Is there Deadlock?

    • Recovery: Preempt Resources from Processes

  • Detection Algorithm

    • When is it Executed?

    • What is its Overhead?

    • Too Often - Wastes Resources

    • Too Infrequent - Blocked Processes Don’t Do Enough Work

  • Dominant Commercial Solution


Deadlock in databases1
Deadlock in Databases

  • Concurrent Access to Database Information

  • Optimistic Concurrency Control

    • Assume Problems Infrequent (ATM Example)

    • Maintain Transaction Log

    • Detect and Correct Errors in System via Log “Long-After” Their Occurrence

    • Similar to What in OS? Deadlock Concepts?

  • Pessimistic Concurrency Control

    • Assume Problems will Occur (Airline Example)

    • Require Transactions to Lock Portions of Data for Read and Write Requests

    • Similar to What in OS? Deadlock Concepts?


Deadlock and concurrency in distributed applications
Deadlock and Concurrency in Distributed Applications

  • Client/Server and Multi-Tiered Architectures Rely Heavily on Concurrency Control

  • At Client/Middle-Server Side

    • Programming Language Support to Allow Concurrent Operations

    • Specialized Processes for Managing Access to Shared Data/Resources

    • Both in Addition to OS Capabilities

  • Database Servers and Management Systems Provide Own Concurrency Control andDeadlock Avoidance, Detection, Prevention


Concurrency in programming languages circa 1995
Concurrency in Programming Languages(Circa 1995)

C-BasedC++Based Distributed OOL Others

Concurr Cob ABC++ Amber A’UM

cooC AKC++ Argus Beta

PROCOL Charm++ Con Meld Blaze 2

Comp C++ DC++ CLIX

Small-Talk Concert C++ DOWL Clueter86

ConSmalltalk Conc C++ DROL Ellie

CST COOOL Dsmalltalk Fleng++

ESP Eden Hybrid

Actor-Based HPC++ Emerald Java

ABCL+ MPC++ Flame (C++) Lamina

Acore Mentat Guile NEXUS

ACT++ PARMACS Heraklit O-CPU

Act1,2,3 PRESTO KITARA Orient 84

Actalk pC++ Must PO

Actra UC++ Orca POOL-T/I

ALBA WARASA SINA

A-NETL ADA95 Solve

Cantor, Janus Extended Eiffel

Plasma-II, Rosette


Recall mbds concurrency control process
Recall MBDSConcurrency Control Process

B3

A1

K12

Request

Preparation

Post

Processing

C4

K12

D6

Put Msg.

Get Msg.

F15 From

Other

Backend

E15 To Backend(s)

Get Msg.

Put Msg.

K12

D6,F15

E15

Record

Processing

I16

Directory

Management

J23

H22

Concurrency

Control

G21

Disk I/O

  • CC Controls Access to Indices, Records, Attributes, etc., All Simultaneously Needed by User Requests


Ct insurance department cc deadlock managed by commercial applications
CT Insurance Department: CC/DeadlockManaged by Commercial Applications

Database

Server

Running

Oracle

Initial Data

Entry Operator

(Scanning & Posting)

Advanced Data

Entry

Operators

Analyst

Manager

10-100MB Network

RMI Registry

Document

Server

Stored

Images/CD

RMI Act.

Obj/Server

RMI Act.

Obj/Server

Functional Server


Rmi unicast remote objects don t interact with one another
RMI: Unicast Remote Objects Don’t Interact with One Another

Adv. Data Entry

Analyst

Manager

rmid

rmiregistry

Server

Activation Object

ActivatableImplementation.java

Unicast Remote Object

LicensingImpl

Unicast Remote Object

LicensingImpl

Unicast Remote Object

LicensingImpl

rmiregistry 1100

rmiregistry 1101

rmiregistry 1102

Document

Server

Stored

Images/CD

Database

Server

Running

Oracle


A formal model for deadlock
A Formal Model for Deadlock Another

  • P = {p1, p2, …, pn} be a set of n Processes

  • R = {R1, R2, …, Rm} be a set of m Resources

  • C = {c1,c2, …, cm), where cj = Number of units of Rj in the System

  • S = {S0, S1, …} be a set of States Representing the Assignment of Resource Rj to Process pi

    • State Changes whenever Processes Take Action

    • This Allows Us to Identify

      • Situations Where Processes are Blocked (e.g. Require Another Process to do Something)

      • Deadlock Situation in the Operating System

  • Formal Model Based on State-Transition Diagram

  • Recall FSM from CSE230


State transitions
State Transitions Another

xi

Sj

Sk

  • System Changes State Due to Action of Process pi

  • There are Three Pertinent Actions:

    • Request:

      • Request One or More Units of a Resource

      • Transition Between States Labeled (“ri”)

    • Allocation:

      • All Outstanding Process Requests for a Given Resource are Satisfied (Transition “ai”)

    • Deallocation :

      • Process Releases Units of a Resource (Transition “di”)


Properties of states
Properties of States Another

a1

r3

Sj

r1

  • Define Deadlock w.r.t. Patterns of Transitions

  • Define: pi is Blocked in Sj if pi Cannot Cause a Transition out of Sj

  • Whyis p2 blocked in Sj ?

    • p2 Can’t Leave on Own

    • Requires Action by Either p1 or by p3

    • Can’t Control Destiny!

  • If pi is Blocked in Sj, and will also be Blocked in every Sk Reachable from Sj, then pi is Deadlocked

  • Sj is Called a Deadlock State


Example
Example Another

  • One Process, Two Units of One Resource

  • Can Request One Unit at a Time

    • r for Request

    • a for Allocated

    • d for Deallocate

  • Two Alternatives

    • Process Can Request, Alloc, Dealloc Twice

    • Process can Request, Alloc, R, A, D, D

  • Eventually Returns to State S0

d

d

r

a

r

a

S0

S1

S2

S3

S4


Extension of example
Extension of Example Another

  • Consider Two Processes Competing for 2 Units of Single Resource

  • Process Limited to Requesting One Unit at Time

  • Process Can’t ask for More than 2 Units

  • How is Prior State Diagram Restructured?

    • Let Sij Refer to P0 in Si and P1 in Sj

    • All States Not Possible

      • S24, S34, S42, S43, S44

      • Some are Unfeasible (S24 - P0 has 1 Unit, P1 has 2)

  • What Does Resulting State Diagram Resemble?


Extension of example1
Extension of Example Another

d0

d0

r0

a0

r0

a0

S00

S10

S20

S30

S40

r1

r1

r1

r1

r1

d0

d0

r0

a0

r0

a0

S01

S11

S21

S31

S41

d1

d1

d1

d1

a1

a1

a1

a1

d0

r0

a0

r0

S02

S12

S22

S32

r1

r1

d0

r1

r1

r0

a0

r0

S03

S13

S23

S33

d1

d1

a1

a1

r0

S04

S14

  • What Does S33 Represent?

  • Impact of More Ps and Rs?


Prevention
Prevention Another

  • Necessary Conditions for Deadlock

    • Mutual Exclusion

    • Hold and Wait

    • Circular Waiting

    • No Preemption

  • Ensure that at Least One of the Necessary Conditions is False at All Times

    • Why Must Mutual Exclusion Hold at All Times?

      • Some Resources (Tape Drive) Must be Exclusively Held by a Process

  • How Can a Prevention Strategy be Designed to Guarantee Failure of One of Other Conditions?


Hold and wait
Hold and Wait Another

  • Invalidate: Hold and Wait: Process Can Hold Resource While Waiting for Another Resource

  • Approach 1: Targeted to Batch Systems

    • Process Must Request All Resources it Needs

    • Process Competes for All Resources Even if Needs Only One Resource at Time

    • Holds Resources “Done” With

  • Approach 2: Targeted to Timesharing

    • For Process to Acquire a Resource

      • Must Release All Held Resources

      • Reacquire All (Released &New) Resources Needed

    • Overhead to Reacquire Held Resources

    • Could Encourage Starvation


Circular wait
Circular Wait Another

Ri

R

P

Pi

P holds R

P

R

P requests R

  • Classic Problem: K Processes Holding Units of K Resources

  • K Processes Want Held Resource from Other K-1 Processes

  • Search for Cycles in Graph


Circular wait continued
Circular Wait (Continued) Another

  • Identifiable Whenever there is a Cycle in the Graph of Processes and Resources

  • What Resource Request Strategy Guarantees No Cycles (i.e., Invalidates Circular Wait)?

    • Total Order of All System Resources!

    • Unique/Numbered System

  • Formally:

    • Total Order on All Resources is Sequencing

    • Process Can Only Ask for Rj If Ri < Rj for All Ri the Process is Currently Holding

    • No Need to Request All at Once

    • However, Can’t go Back to Get One “Missed”


Revisit dining philosophers problem
Revisit Dining Philosophers Problem Another

philosopher(int i) {

while(TRUE) {

// Think

// Eat

P(fork[i]);

P(fork[(i+1) mod 5]);

eat();

V(fork[(i+1) mod 5]);

V(fork[i]);

}

}

semaphore fork[5]=(1,1,1,1,1);

fork(philosopher, 1, 0);

fork(philosopher, 1, 1);

fork(philosopher, 1, 2);

fork(philosopher, 1, 3);

fork(philosopher4, 0);

philosopher4() {

while(TRUE) {

// Thinking ...

P(fork[0]);

P(fork[4]);

eat();

V(fork[4]);

V(fork[0]);

}

}


Allowing preemption
Allowing Preemption Another

ru

Si

Sj

wu

dv

ru

Sk

  • Invalidate Preemption: Allow a Process to Time-out on a Blocked Request

  • Thus, Process Withdraws the Request If It Fails

  • Consider State Transition Diagram Below

  • Technique Prevents Deadlock via Withdrawal

  • Allows Other Processes that Might Need ru to Go

  • May Result in Livelock Where Processes are Requesting & Withdrawing without Useful Work


Avoidance
Avoidance Another

  • Requires a Multi-Phase Approach

    • Construct a Model of System States

    • Choose a Strategy that Guarantees that the System Will Not Go to a Deadlock State

    • Service Processes in Some Order, Not Necessarily Order Received

  • Requires Extra Information for Each Process

    • Maximum Claim - Maximum Number of Units of Every Resource Process Will Ever Request

  • Resource Manager Sees the Worst Case and can Allow Transitions Based on that Knowledge

  • Goal: To Maintain “Safe” State


Safe vs unsafe states
Safe vs. Unsafe States Another

  • Defining a Safe State:

    • There is Guaranteed to be a Sequence of Transitions that Leads Back to the Initial State

    • Even If All Process Exercise their Maximum Claim, there is an Allocation Strategy by Which All Claims Can Be Met

  • Defining an Unsafe State:

    • System Cannot Guarantee there is Such a Sequence

    • Unsafe State Can Lead to a Deadlock State if too Many Processes Exercise Their Maximum Claim at Once

  • What is Global Perspective of Concepts?


More on safe unsafe states
More on Safe & Unsafe States Another

Likely to be in a safe state

Normal

Execution

No

Request Max Claim

Yes

Execute, then

release

Probability of being in unsafe state increases


More on safe unsafe states1
More on Safe & Unsafe States Another

Normal

Execution

No

Request Max Claim

Yes

Execute, then

release

  • Suppose all Processes take “yes” Branch

  • Avoidance Strategy is to Allow this to Happen, yet Still be Safe

  • Some Sequence of Allocs and Deallocs to Allow Processes to do Maximum Claims


More on safe unsafe states2
More on Safe & Unsafe States Another

Safe States

Unsafe States

Deadlock States


Banker s algorithm definitions
Banker’s Algorithm AnotherDefinitions

  • Let maxc[i, j] be a 2-D Array that Contains the Maximum Claim for Resource Rj by Process pi

  • Let alloc[i, j] be a 2-D Array that Contains the Number of Units of Resource Rj held by Process pi

  • Let C[j] be Units of Resource Rj

  • Given maxc and alloc, we Can Always Compute:

    • System Resource Units - Resource Units Held

    • avail[j] = cj -  0i< n (alloc[i,j])

    • Represents Available Units of Rj

  • Given “Available Units”, is there a Process that can Execute (i.e., is this a Safe State)? If So,

    • Execute Process, Dealloc Resources, Adjust Arrays, and Recalculate and Iterate


Banker s algorithm
Banker’s Algorithm Another

1. Copy the alloc[i,j] Table to alloc’[i,j]

2. Given C, maxc, and alloc’, Compute avail Vector

3. Find pi: maxc[i,j] - alloc’[i,j]  avail[j]for 0  j < m and 0  i < n

If no such pi Exists, the State is Unsafe - Halt

If alloc’[i,j] is 0 for all i and j, the State is Safe - Halt: Algorithm Done - All Processes Executed

4. Set alloc’[I,j] to 0; Deallocate all Resources held by pi; go to Step 2


Example start with maxc alloc c
Example: Start with maxc, alloc, C Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 4 0 0 3

p3 0 2 1 0

p4 1 0 3 0


Example1
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Compute Total Held = <7,3,7,5>

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 4 0 0 3

p3 0 2 1 0

p4 1 0 3 0

Sum 7 3 7 5


Example2
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Compute Total Held = <7,3,7,5>

  • Find Available Units (C-Held)

avail = <8-7, 5-3, 9-7, 7-5>

= <1, 2, 2, 2>

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 4 0 0 3

p3 0 2 1 0

p4 1 0 3 0

Sum 7 3 7 5


Example3
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Compute Total Held = <7,3,7,5>

  • Find Available Units (C-Held)

avail = <8-7, 5-3, 9-7, 7-5>

= <1, 2, 2, 2>

  • Can p0’s maxc be met?

maxc[0,0]-alloc’[0,0] = 3-2 = 11 = avail[0]

maxc[0,1]-alloc’[0,1] = 2-0 = 22 = avail[1]

maxc[0,2]-alloc’[0,2] = 1-1 = 02 = avail[2]

maxc[0,3]-alloc’[0,3] = 4-1 = 32 = avail[3]

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 4 0 0 3

p3 0 2 1 0

p4 1 0 3 0

  • Process p0 Fails on avail[3]

Sum 7 3 7 5


Example4
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Compute Total Held = <7,3,7,5>

  • Find Available Units (C-Held)

avail = <8-7, 5-3, 9-7, 7-5>

= <1, 2, 2, 2>

  • Can p1’s maxc be met?

maxc[1,0]-alloc’[1,0] = 0-0 = 01 = avail[0]

maxc[1,1]-alloc’[1,1] = 2-1 = 12 = avail[1]

maxc[1,2]-alloc’[1,2] = 5-2 = 32 = avail[2]

maxc[1,3]-alloc’[1,3] = 2-1 = 12 = avail[3]

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 4 0 0 3

p3 0 2 1 0

p4 1 0 3 0

  • Process p1 Fails on avail[2]

Sum 7 3 7 5


Example5
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Compute Total Held = <7,3,7,5>

  • Find Available Units (C-Held)

avail = <8-7, 5-3, 9-7, 7-5>

= <1, 2, 2, 2>

  • Can p2’s maxc be met?

maxc[2,0]-alloc’[2,0] = 5-4 = 11 = avail[0]

maxc[2,1]-alloc’[2,1] = 1-0 = 12 = avail[1]

maxc[2,2]-alloc’[2,2] = 0-0 = 02 = avail[2]

maxc[2,3]-alloc’[2,3] = 5-3 = 22 = avail[3]

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 4 0 0 3

p3 0 2 1 0

p4 1 0 3 0

Sum 7 3 7 5


Example6
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Compute Total Held = <7,3,7,5>

  • Find Available Units (C-Held)

avail = <8-7, 5-3, 9-7, 7-5>

= <1, 2, 2, 2>

  • Can p2’s maxc be met?

maxc[2,0]-alloc’[2,0] = 5-4 = 11 = avail[0]

maxc[2,1]-alloc’[2,1] = 1-0 = 12 = avail[1]

maxc[2,2]-alloc’[2,2] = 0-0 = 02 = avail[2]

maxc[2,3]-alloc’[2,3] = 5-3 = 22 = avail[3]

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 4 0 0 3

p3 0 2 1 0

p4 1 0 3 0

  • Yes! Redo avail/Update alloc’

avail[0] = avail[0]+alloc’[2,0] = 1+4 = 5

avail[1] = avail[1]+alloc’[2,1] = 2+0 = 2

avail[2] = avail[2]+alloc’[2,2] = 2+0 = 2

avail[3] = avail[3]+alloc’[2,3] = 2+3 = 5

Sum 7 3 7 5


Example7
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Recompute Total Held=<3,3,7,2>

  • Find Available Units (C-Held)

avail = <8-3, 5-3, 9-7, 7-2>

= <5, 2, 2, 5>

  • Can anyone’s maxc be met?

maxc[4,0]-alloc’[4,0] = 5-1 = 45 = avail[0]

maxc[4,1]-alloc’[4,1] = 0-0 = 02 = avail[1]

maxc[4,2]-alloc’[4,2] = 3-3 = 02 = avail[2]

maxc[4,3]-alloc’[4,3] = 3-0 = 35 = avail[3]

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 0 0 0 0

p3 0 2 1 0

p4 1 0 3 0

Sum 3 3 7 2


Example8
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Recompute Total Held=<3,3,7,2>

  • Find Available Units (C-Held)

avail = <8-3, 5-3, 9-7, 7-2>

= <5, 2, 2, 5>

  • Can anyone’s maxc be met?

maxc[4,0]-alloc’[4,0] = 5-1 = 45 = avail[0]

maxc[4,1]-alloc’[4,1] = 0-0 = 02 = avail[1]

maxc[4,2]-alloc’[4,2] = 3-3 = 02 = avail[2]

maxc[4,3]-alloc’[4,3] = 3-0 = 35 = avail[3]

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 0 0 0 0

p3 0 2 1 0

p4 1 0 3 0

  • P4 can exercise max claim

avail[0] = avail[0]+alloc’[4,0] = 5+1 = 6

avail[1] = avail[1]+alloc’[4,1] = 2+0 = 2

avail[2] = avail[2]+alloc’[4,2] = 2+3 = 5

avail[3] = avail[3]+alloc’[4,3] = 5+0 = 5

Sum 3 3 7 2


Example9
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Recompute Total Held=<2,3,4,2>

  • Find Available Units (C-Held)

avail = <8-2, 5-3, 9-4, 7-2>

= <6, 2, 5, 5>

  • Can anyone’s maxc be met?

  • Yes, any of them can!

  • Choose p0

Allocated Resources

Process R0 R1 R2 R3

p0 2 0 1 1

p1 0 1 2 1

p2 0 0 0 0

p3 0 2 1 0

p4 0 0 0 0

Sum 2 3 4 2


Example10
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Recompute Total Held=<0,3,4,2>

  • Find Available Units (C-Held)

avail = <8-0, 5-3, 9-4, 7-2>

= <8, 2, 5, 5>

  • Can anyone’s maxc be met?

  • Yes, any of them can!

  • Choose p1

Allocated Resources

Process R0 R1 R2 R3

p0 0 0 0 0

p1 0 1 2 1

p2 0 0 0 0

p3 0 2 1 0

p4 0 0 0 0

Sum 0 3 4 2


Example11
Example Another

C = <8, 5, 9, 7>

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

  • Recompute Total Held=<0,2,1,0>

  • Find Available Units (C-Held)

avail = <8-0, 5-2, 9-1, 7-0>

= <8, 3, 8, 7>

  • Can anyone’s maxc be met?

  • Yes, Choose p3

Allocated Resources

Process R0 R1 R2 R3

p0 0 0 0 0

p1 0 0 0 0

p2 0 0 0 0

p3 0 2 1 0

p4 0 0 0 0

Sum 0 2 1 0


Example summary

Alloc’ Now Zeroed Another

Safe State with All Processes Completed

Halt Algorithm with Success

Process Order of

p2, p4, p0, p1, p3

Safe Execution

All Maximum Claims Satisfied in Some Order

No Deadlock or Unsafe State

Example: Summary

Maximum Claim

Process R0 R1 R2 R3

p0 3 2 1 4

p1 0 2 5 2

p2 5 1 0 5

p3 1 5 3 0

p4 3 0 3 3

Allocated Resources

Process R0 R1 R2 R3

p0 0 0 0 0

p1 0 0 0 0

p2 0 0 0 0

p3 0 0 0 0

p4 0 0 0 0

Sum 0 0 0 0


Detection recovery
Detection & Recovery Another

  • Check for Deadlock (Periodically or Sporadically), Then Recover

  • Resource Manager Can Be Far More Aggressive With Allocation

  • No Maximum Claim, No Safe/Unsafe States

  • Differentiate Between

    • Serially Reusable Resources:

      • Unit Must Be Allocated Before Being Released

      • Strict Time-Multiplexing Sharing Approach

    • Consumable Resources:

      • Never Release Acquired Resources

      • Resource Count is Number Currently Available


Reusable resource graphs rrgs
Reusable Resource Graphs (RRGs) Another

  • Micro Model to Describe a Single State

  • Nodes = {p0, p1, …, pn}  {R1, R2, …, Rm}

  • Processes are Circles; Resources are Boxes

  • Edges Connect pi to Rj or Rj to pi

    • (pi, Rj) is Request Edge for one Unit of Rj

      • If pi Needs Multiple Rjs, Multiple Request Edges

    • (Rj, pi) is Assignment Edge of one Unit of Rj

      • If pi Uses Multiple Rjs, Multiple Assignment Edges

  • For each Rj there is a Count, cj of Units Rj

  • Number of Units of Rj Allocated to pi Plus the Number Requested by pi Cannot Exceed cj

    • Process Cannot Request 10 R1 if Only 8 Units


Example12

Note Arrow From Token (Resource) to Process Another

Represents Resource Being Used by Process

Overall: Represents a Deadlock State

Example

R

p

P holds one unit of R

P requests one unit of R

p

R


Example13
Example Another

Why is Above

Not a Deadlock State?

What has Happened to

Transition to Above?


State transitions within rrgs
State Transitions within RRGs Another

  • Transitions in Diagrams are Based on Events:

    • Release Allocated Resource via Deallocate Event d

    • Request Resource via Request Event r

    • Allocated a Requested Resource via Allocate Event a

  • Request, Alloc, Dealloc Operate within Context of Specific Allocation Policy by Resource Manager

  • Classic Resource Allocation Policy Composed of

    • Request for Resources (Request Edges)

    • Acquisition of Resources (Assignment Edges)

    • Release of Resources (Remove of Edges)


State transitions for request event
State Transitions for Request Event Another

q edges

pi

Rh

pi

Rh

pi request q units

State Sk

State Sj

of Rh

  • Suppose Process pi, State Sj, Resource Rh

    • pi is Allowed to Request qch Units of Rh

    • Only if pi has no Outstanding Requests for Any Resources

  • Transition from Sj  Sk

    • Evolve RRG for Sj

    • RRG for Sk is Derived from Sj by Adding q Request Edges from pi to Rh


State transition for acquire event
State Transition for Acquire Event Another

  • Suppose Process pi, State Sj, Resource Rh

    • pi is Allowed to Acquire Units of Rh iff there is (pi, Rh) Request Edge in the Graph and all Requests Satisfied on All Resources at Once

  • Transition from Sj  Sk

    • RRG for Sk is Derived from Sj by Changing each Request Edge to an Assignment Edge

    • Assignment Edge from Unit/Token!

pi

Rh

pi

Rh

pi acquires units

State Sk

State Sj

of Rh


State transition for release event
State Transition for Release Event Another

  • Suppose Process pi, State Sj, Resource Rh

    • pi is Allowed to Release Units of Rh iff there is Assignment Edge (Rh, pi) in the Graph, and there is no Request Edge from pi to Rh.

  • Transition from Sj  Sk

    • RRG for Sk is Derived from Sj by Deleting all Assignment Edges

pi

Rh

pi

Rh

pi releases units

State Sk

State Sj

of Rh


Example14

p0 and p1 are Processes Another

Both Require 2 Units of Same Resource to Run

What is Sequence of

Request

Acquisition

Example

p0

p1

S00


Example Another

  • p1 Request

p0

p0

p1

p1

S00

S01


Example Another

  • p0 Request

p0

p0

p0

p1

p1

p1

S00

S01

S11


Example Another

  • p0 Acquisition

p0

p0

p0

p0

p1

p1

p1

p1

S00

S01

S11

S21


Example Another

  • p1 Acquisition

p0

p0

p0

p0

p0

p1

p1

p1

p1

p1

S00

S01

S11

S21

S22


Example Another

  • p0 and p1 Request

p0

p0

p0

p0

p0

p0

. . .

p1

p1

p1

p1

p1

p1

What is True About S33?

S00

S01

S11

S21

S22

S33


Analyzing rrgs
Analyzing RRGs Another

  • RRG Provide Mechanism for Tracking Process’ Requested, Acquired, and Released Resources

  • Given RRG can Transition from One State to Next based on Actions of Processes Under Control of Resource Manager

  • Resource Manager Must be Able to Analyze RRG to Determine if

    • Current Requests and Acquisitions for All Processes Can Lead to Deadlock

    • Achieve by Examining if Process is “Blocked”

  • Resource Manager Performs Transformations or Graph Reductions on RRGs to Unblock Processes


Graph reduction for rrgs
Graph Reduction for RRGs Another

  • Deadlock State if there is No Sequence of Transitions Unblocking Every Process

    • RRG Represents a State

    • Can Analyze the RRG to Determine if there is a Sequence of Actions to Unblock Graph

    • Unblock to RRG with No Edges

  • Graph Reduction Represents the (Optimal) Action of an Unblocked Process

  • RRG Can be Reduced by pi if

    • pi is Not Blocked

    • pi has No Request Edges

    • There are Assignment Edges (Rj, pi) in RRG


Graph reduction for rrgs continued
Graph Reduction for RRGs (Continued) Another

  • Transform RRG to Another RRG With All Assignment Edges into Process pi Removed

  • Represents pi Releasing the Resources it Holds

pi

Reducing by pi

pi

  • RRG is Completely Reducible if there a Sequence of Reductions that Leads to a RRG With No Edges

  • A State is a Deadlock State If and Only If the RRG is Not Completely Reducible (Irreducible)


Example rrg

Again, Which Process Can be Reduced on Right Based on Another

Holding Required Resources

Able to Acquire Requested Resource

Graph is Reducible via p1!

Which Process Can be Reduced on Left Based on

Holding Required Resources

Able to Acquire Requested Resource

Graph is Reducible via p0!

Example RRG

p0

p0

R0

R0

R2

R2

p1

p1

p2

p2

R1

R1


Example rrg1
Example RRG Another

R0

R0

R2

R2

R1

R1

p0

p0

p1

p1

p2

p2

  • Now, Graph is Reducible by p2

  • Resulting Graph has No Edges

  • Hence Completely Reducible

  • No Deadlock State Possible

  • Resource Manager Can Execute as Follows

    • p0 Gets R0, Executes, Releases

    • p1 Gets 2 R0, Executes, Releases

    • p2 Gets 1 R1 and 1 R2, Executes, Releases


Second Example RRG Another

p0

R0

R2

p1

p2

R1

  • Consider Following RRG

  • What is State of RRG?

    • p0 Has R1& Requests R2

    • p1 Has R0& Requests R1

    • p2 Has 2 R1& Requests R1

  • All Resources Held

  • No Resources Available

  • Irreducible State

  • Resource Manager Detects

  • Intervention to Kill Process to Allow Others to Proceed

  • Must Restart Killed Process


Consumable resource graphs crgs
Consumable Resource Graphs (CRGs) Another

  • Contrast with RRGs on

    • Number of Resource Units Variable/Dynamic

    • Producers of Units/Consumers of Units

  • Nodes = {p0, p1, …, pn}  {R1, R2, …, Rm}

  • Edges From Process pi to Resource Rj or Rj to pi

    • (pi, Rj) is a Request Edge for one unit of Rj

    • (Rj, pi) is an Producer Edge

      • Must have at Least One Producer for each Rj

      • Can be Multiple Producers for each Rj

  • For each Rj here is a Current Count wj of Units Rj


State transitions for request event1
State Transitions for Request Event Another

  • Suppose Process pi, State Sj, Resource Rh

    • pi Can Request any Number of Units of Rh

    • pi Must have no Outstanding Requests

  • Transition from Sj  Sk

    • RRG for Sk is Derived from Sj by Adding q Request Edges from pi to Rh

q edges

pi

Rh

pi

Rh

pi request q units

State Sk

State Sj

of Rh


State Transition for Acquire Event Another

  • Suppose Process pi, State Sj, Resource Rh

    • pi Can Acquire Units of Rh iff there is Request Edge (pi, Rh) in the Graph and All Such Requests can be Satisfied at Once

  • Transition from Sj  Sk

    • RRG for Sk is Derived from Sj by Deleting Each Request Edge and Decrementing wh

pi

Rh

pi

Rh

pi acquires units

State Sk

State Sj

of Rh


State Transition for Release Event Another

  • Suppose Process pi, State Sj, Resource Rh

    • pi Can Release Units of Rh iff there is Request Edge (Rh, pi) in the Graph and There is no Request Edge from pi

  • Transition from Sj  Sk

    • RRG for Sk is Derived from Sj by Incrementing wh

pi

Rh

pi

Rh

pi releases units

State Sk

State Sj

of Rh


Example Another

p0 Requests

2 Resource

Units

p0 Acquires

2 Resource

Units

p1 Produces

Resource

p0

p0

p0

p0

p0

p0

p1

p1

p1

p1

p1

p1

p1 Produces

Resource

p1 Produces

Resource

p1 Producer

of Resource


Deadlock detection
Deadlock Detection Another

p1

p0

  • May Have a CRG that is Not Completely Reducible, but it is Not a Deadlock State

  • For Each Process: Find at Least One Sequence Which Leaves Each Process Unblocked

  • There May Be Different Sequences for Different Processes -- Not Necessarily an Efficient Approach

See Figures

10.26

10.27

10.28

and Discussion


General resource graphs
General Resource Graphs Another

  • In Practice, Resource Managers Must Oversee Both Consumable and Reusable Resources

  • Resource Manager has: General Resource Graphs

  • Reductions as Follows:

    • Apply Consumable Reductions to CRGs

    • Apply Reusable Reductions to RRGs

  • For Deadlock Free

    • Reusable Resources Must be Isolated by Reductions

    • CRG Must have Sequence without Blocking

  • See Figure 10.29


Grg example fig 10 29
GRG Example (Fig 10.29) Another

p3

p2

R0

R2

R1

p0

p1

Reusable

Consumable

Not in Fig 10.29


GRG Example (Fig 10.29) Another

p3

p2

Reduce by p3

R0

R2

R1

p0

p1

Reusable

Consumable


GRG Example (Fig 10.29) Another

p3

p2

R0

R2

R1

p0

p1

Reduce by p0

Reusable

Consumable


Recovery
Recovery Another

  • Detection Process Must be Followed by Recovery

  • Move System to Another State without Deadlock

  • No Magic Here

    • Choose a Blocked Process

    • Preempt it (Releasing its Resources)

    • Run the Detection Algorithm

      • RRGs and CRGs

    • Iterate Until the State is Not a Deadlock State

      • Choose Blocked Process

      • Preempt it and Release its Resources … etc …


Concluding remarks looking ahead
Concluding Remarks/Looking Ahead Another

  • Deadlock

    • Strategies for Prevention, Avoidance, Detection & Recovery

    • Algorithm/Formal Models Usable by Resource Manager to Control System State

  • Interesting Exercise 2, 6, 7, 8 in Section 10.7

    • Exercise 2: Banker’s Algorithm

    • Others RRG, CRG, GRG Exampes

  • Looking Ahead to …

    • Memory Management (Chapter 11)

    • Virtual Memory/Paging (Chapter 12)

    • JINI Project


ad