Deadlocks - II - PowerPoint PPT Presentation

1 / 29
About This Presentation
Title:

Deadlocks - II

Description:

If P1 requests max resources, can complete. Process. Alloc. Max. Need. Available. A. B. C ... Try to Allocate 2 B to P0. CS423UG - Operating Systems, Indranil ... – PowerPoint PPT presentation

Number of Views:33
Avg rating:3.0/5.0
Slides: 30
Provided by: yuanyu1
Category:
Tags: deadlocks

less

Transcript and Presenter's Notes

Title: Deadlocks - II


1
Deadlocks - II
CS423UG Operating Systems
  • Indranil Gupta
  • Lecture 12
  • Sep 21, 2005

2
Agenda
  • Deadlock avoidance
  • Deadlock detection

3
Review
  • Resources can be of different types
  • Necessary conditions for a Deadlock
  • Mutual exclusion
  • Hold and wait
  • Non-preemption
  • Circular wait
  • Deadlock prevention
  • Ensure at least one of conditions 1-4 is always
    false
  • Use 2-phase locking

4
Deadlock Avoidance
  • Each resource has multiple instances
  • The system needs to know the maximum resource
    requirements of each process ahead of time
  • Process p specifies, for each resource i,
    p.Maxi
  • Bankers Algorithm (Dijkstra, 1965)
  • Each customer tells banker the maximum number of
    resources it needs
  • Customer borrows resources from banker
  • Customer returns resources to banker
  • Banker only lends resources if the system will be
    in a safe state after the loan
  • Safe state - there is a lending sequence such
    that all customers will be able to take out a
    loan
  • Unsafe state - there is a possibility of deadlock

5
Safe State and Unsafe State
  • Safe State
  • Can guarantee there is some scheduling order in
    which every process can run to completion even if
    all of them suddenly request their maximum number
    of resources immediately
  • From safe state, the system can guarantee that
    all processes will finish
  • Unsafe state no such guarantee
  • A deadlock state is an unsafe state
  • An unsafe state may not be a deadlock state
  • Some process may be able to complete
  • A conservative/pessimistic approach

6
How to Compute Safety
  • Given
  • n different types of resources
  • Set P of processes, with each process p
    specifying p.Max1n
  • For each p and i, the number of instances of
    resource i held by p currently p.Alloci
    (has to be lt p.Maxi)
  • Current numbers of available resources of each
    type Available1n
  • Let
  • For each process p and resource i, let
    p.Needip.MAXi-p.Alloci
  • while ( there exists a p in P such that
  • for all i (p.Needi lt Availablei )
  • )
  • do for all i
  • Availablei p.Alloci
  • P P - p
  • If P is empty then system is safe

7
Is Allocation (1 0 2) to P1 Safe?
If P1 requests max resources, can complete
8
Run Safety Test
If P1 requests max resources, can complete
9
Allocate to P1, Then

10
Release - P1 Finishes
Now P3 can acquire max resources and release
11
Release - P3 Finishes
Now P4 can acquire max resources and release
12
Release - P4 Finishes
Now P2 can acquire max resources and release
13
Release - P2 Finishes
Now P0 can acquire max resources and release
14
So P1 Allocation (1 0 2) Is Safe
15
Is allocation (0 2 0) to P0 Safe?
Try to Allocate 2 B to P0
16
Run Safety Test
No Processes may get max resources and release
17
Avoid Unsafe State- Do Not give (0,2,0) to P0
Return to Safe State and do not allocate resource
18
Suspend P0, Pending Request
When enough resources become available, P0 can be
woken
19
Results
  • P0s request for 2 Bs cannot be granted because
    that would prevent any other process from
    completing if they need their maximum claim

20
Just Because Its Unsafe Doesnt mean
  • P0 could have been allocated 2 Bs and a deadlock
    might not have occurred if
  • P2 didnt use its maximum resources but finished
    using the resources it had

21
If no other process uses up Max
Then P0 would have finished
22
Tradeoff
  • The bankers algorithm is conservative --- it
    reduces parallelism for safety sake

23
Banker Algorithm Issues
  • Process may request more than claim
  • A process may suffer indefinite postponement
    (starvation)
  • Solution is to check for aged process
  • Select an allocation sequence that includes aged
    process
  • Only select requests that follow that sequence
    until aged process executes

24
Deadlock Detection
  • Check to see if a deadlock has occurred!
  • Single resource per type
  • Can use wait-for graph
  • Check for cycles
  • O(n2)

25
Wait for Graphs
Resource Allocation Graph
Corresponding Wait For Graph
26
Multiple resources per type
  • Run variant of bankers algorithm to see if
    processes can finish
  • time O(mn2), m resources, n processes
  • Optimistic version check only that at least one
    process can finish
  • The deadlock detection is delayed
  • Issues
  • How often should the detection algorithm be run?
  • How comprehensive should it be each time it is
    run?

27
Recovery From Deadlock
  • Options
  • Kill all deadlocked processes and release their
    resources
  • Kill one deadlocked process at a time and release
    its resources, until no more deadlock
  • Rollback (undo) all or one of the processes to a
    checkpoint that occurred before they requested
    any resources
  • Note with rollback, starvation could occur
    (why?)

28
Deadlocks Summary
  • In general, deadlock detection or avoidance is
    expensive
  • Must evaluate cost of deadlock against detection
    or avoidance costs
  • Deadlock avoidance and recovery may cause
    starvation
  • Unix and Windows use Ostrich Algorithm

29
Reminders
  • Reading for this lecture Chapter 3 (except
    Section 3.8)
  • Reading for next lecture Sections 4.1-4.2
  • Memory Management
  • HW2 due this Friday.
  • HW3 out this Friday, due in 1 week (short fuse!).
    Last HW before midterm.
Write a Comment
User Comments (0)
About PowerShow.com