• 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
  1. mutual exclusion
  2. no preemption
  3. hold-and-wait
  4. 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
  1. mutual exclusion: instances
  2. hold and wait: assignment AND request
  3. no preemption: nature of assignment
  4. 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