Lecture 012

Deadlock Prevention

Simplist Form: both process want each other's resources but don't want to let go of their own first. Less-obvious: Three process all just want "one more" resource

Four properties of Deadlock: (every deadlock must have these four properties)

1. Mutual Exclusion: resources non-sharable
2. Hold and Wait: grab multiple locks at the same time
3. No Preemption: can't force a process to give up a resource
4. Circular Wait: there is a circular dependency in resource needs

Note that if a situation satisfies all four properties, it doesn't mean it is a deadlock.

Dining philosophers problem:

• five philosopher sitting around a table

• 5 bowls

• 5 chopsticks

Policy 1:

1. wait to grab chopstick to the left
2. wait to grab chopstick to the right (probably not gonna happen ever)
3. eat for a while
4. put chopsticks back

Policy 2:

1. put the mutex to the while table
2. ==== grab the mutex ====
3. while-cond-wait on left chopstick
4. while-cond-wait on right chopstick
5. grab both chopsticks
6. ==== release the mutex ====
7. eat for a while
8. ==== grab the mutex ====
9. cond-signal left chopstick
10. cond-signal right chopstick
11. ==== release the mutex ====

4 solutions to deadlock:

1. prevent: disallow 1 of 4 properties
   • outlaw mutual exclusion: make all resources sharable (e.g. read-only files)
     • problem: not all resources can be sharable
   • outlaw hold and wait: require processes to grab all resources at once (e.g. grab both chopsticks at the same time)
     • problem: starvation (large resource set making grabbing one hard)
     • problem: utilization (is a resources is not used very often during computation, it still needs to be grabbed at the beginning and release at the end)
   • outlaw no preemption: if a process is waiting for a resource, preempt it
     • problem: not all resources can be preempted (e.g. printer)
   • outlaw circular wait: impose a total ordering of resources and everybody require processes to grab resources in order, if not possible, release all and re-grab in order
     • problem: not all resources can be ordered (e.g. "locking train" example, a train needs to grab the track where it stands, however, the tracked is shared between forward and backward trains. Locking in order means locking the entire track before going.)
     • problem: release and re-grab can be annoying and potentially cause starvation
2. avoid: pre-declare usage pattern, dynamic examine requests, keep system safe
3. detect and recover: when "too quiet", analyze cycle, kill some process
   • deadlock can have changing states, deadlocks might not be "too quiet"
4. reboot when "too quiet"
   • deadlock can have changing states, deadlocks might not be "too quiet"