CSE 7343/5343, Spring 2003
Topic 2-1: Deadlocks
Prof. Jeff Tian, CSE/SoE/SMU, Dallas, TX 75275
tian@engr.smu.edu; www.engr.smu.edu/~tian/class/7343.03s
- Dates: 2/18-25/03.
- Reading: Ch8.
Exam#1 results and other announcements
- general result
- individual results to in-class students
- concerned students: see me at my office hours
- specific problems will be discussed later
- distinguished lecture on 3/19/03
- related office hour changes
Deadlock concepts and necessary conditions
- deadlock example
- traffic deadlock, Fig 8.8 (p.267)
- deadlock in C.S. solution
(Algorithm 2. flags)
- deadlock in dining philosophers
(symmetric solution)
- interlock example
improper use of semaphores
- in OS, involving resource usage
- usage sequence: request, (allocation), use, release
- where does it occur?
- general concept
deadlock: no progress possible
- connection to usage sequence
request phase
- consequence of deadlock
- not only affect those processes in deadlock
- other processes: reduced system resource
- more likely to have more deadlock
- complete system shut-down (total deadlock)
- necessary conditions for deadlock
- mutual exclusion
- no preemption
- hold-and-wait
- circular wait
- why?
illustrative examples for each conditions
- circular wait => hold-and-wait
but it makes sense to consider separately
in dealing with deadlocks (later)
Deadlock modeling and handling
- RAG = resource allocation graph
- processes P = { P1, P2, ..., Pn }
represented as circles
- resources R = { R1, R2, ..., Rm }
represented as blocks/rectangles
instances as dots within
- request: arc/edge/link from Pi to Rj
- allocation: arc/edge/link from Ri to Pj
- RAG directed graph
- necessary condition in RAG
- example of RAGs
- dealing with deadlocks
- generic ways:
- prevention: break some necessary conditions
- avoidance: exist allocation sequence?
future request and allocations
- detection and recovery
detection algorithm
recovery methods
- do nothing, restart if system crash/stop
- common analysis: RAG-based
- algorithms and specifics with each technique
- hierarchy/organization of deadlock handling strategies
- do-nothing vs. do-something
- possibly allow deadlock to occur or not
=> detection/recovery vs prevention&avoidance
(do-something)
- work with necessary conditions or general case
=>nec. cond.: prevention
general case: avoidance
(deadlock never occurs)
- similarities to dealing with defects
- prevention
via education, process, technology/methodology, etc.
- detection and removal
via testing, inspection, etc.
- tolerance and containment
via fault tolerance, interlocks, etc.
Dealing with deadlocks: Prevention
- idea: break one/more of the necessary conditions
- mutual exclusion: really necessary?
analyze => not really, share
ways to share: (context) switching, duplication,
break down resources (groups) into smaller units.
yes, other conditions or other techniques
- hold-and-wait:
all request at beginning
request only if not wait
2 phases, no hold and wait
related problems: utilization
starvation possibility
- no preemption:
forced preemption
while making request
later, to break deadlock
- circular wait:
resource ordering solution
detection if given
- analysis of deadlock prevention with RAG
- mutual exclusion: instances
- hold and wait: assignment AND request
- no preemption: nature of assignment
- circular wait: cycles in RAG
- necessary or sufficient condition
- general: RAG cycle = necessary condition
- single instances of Ri, for all i
RAG cycle = sufficient condition
- examples in class
from book: Figs 8.2-3 (p.248-249)
- single instance example
Dealing with deadlocks: Avoidance
- basic idea
- future resource request information
- if allocated => deadlock or unsafe, then don't
- otherwise, allocate
- single instance: cycle after hypothetical allocation?
- general: use detection/safety algorithm (later)
- key: exist a sequence to satisfy all future request
- "safe" vs. "unsafe" state
- any allocation will keep it in the safe state
Dealing with deadlocks: detection and recovery
- deadlock detection
- single instance: cycle in RAG
- simplified model: wait-for graph
- general algorithm:
- request satisfied => can finish
- finish => release all allocated resource
- can any other requests be satisfied afterward?
- all can finish = deadlock free
- otherwise, some deadlocked (unable to finish)
- algorithm on p.262
- when to run detection algorithm:
- how likely it's going to happy?
- impact? processes/resources involved
- overhead for running the algorithm
- overhead for related recovery
- deadlock recovery
- 2 ways: process termination or preemption
- termination strategies:
- all deadlocked processes
- one at a time until deadlock broken
- advantages and disadvantages
- termination selection:
- process priority and type
- computational considerations: how far along?
- resources: allocated vs future
- impact on other processes
- 6 considerations in your book
- preemption
- which one? similar to termination selection
- rollback: how? similar to context switching
- starvation possibility
Dealing with deadlocks: Avoidance revisited
- Banker's algorithm
- "safe" vs. "unsafe" state
- keeping track of resources/allocations/needs
available/max/allocation/need on p.257
- allocation leave system in safe state
allocation algorithm on p.258
- how to determine if it is "safe"?
- safety algorithm on p.258
- all future needs can be satisfied?
- run deadlock detection algorithm on future needs
- as compared to on current requests
Comparison of deadlock handling techniques
- impact on performance: resource utilization, throughput, etc.
- overhead/cost issues: setup, complexity, frequency, recover, etc.
- main alternatives: prevention, avoidance, detection&recovery, do nothing
Prepared by Jeff Tian
(tian@engr.smu.edu).
Last update March 5, 2003.