Deadlock

- 4 conditions must hold (necessary) for deadlock to occur:
	- mutual exclusion: 
		- resource is not shared; process has exclusive control
	- hold and wait: 
		- process may hold one resource and request another
	- circular waiting:
		- p1 may hold R1 and request R2
		- p2 may hold R2 and request R1
		- (can extend to > 2 processes)
	- no preemption:
		- only the process holding a resource can release it
		- process does not withdraw resource request if
		  if it is unavailable
- gridlock example

Dealing with Deadlock
	- prevention
	- detection/recovery
	- avoidance

Introduce state transition diagram

	    request Rs	      allocate Rs	release Rs
	Si -------------> Sj -------------> Sk -------------> Sl
	   <-------------		    |
            withdraw			    | request Rt
					    v
					   Sm

	- sequence of requests, allocations, deallocations, etc.

Prevention
	- conservative scheme: undercommits resources
	- mutual exclusion
		- nothing can be done about that!
	- break hold and wait
		a) process must request all resources at once
			- hard to know all future resource needs
			- not plausible for interactive systems
		b) process must release all resources before 
		   requesting new ones
			- huge overhead: closing files, re-opening, etc.
			- may lead to starvation 
	- break cycle
		a) don't allow cycles in process-resource graph
			- e.g. the reverse direction dining philosopher
		b) total order:
			- establish total order on all resources
			  (consumable and renewable)
			- process can only request resource Rj if
			  for all Rk held process, j > k
			- otherwise, must first release all Rk 
			  where k > j, then reaquire
	- allow preemption
		- if requested resource not available immediately,
		  process withdraws request and does something else
		- assumes that process always has "something else" to do
		- can lead to livelock: processes running, but not 
		  doing anything useful

Detection
	- liberal: grant resources wherever possible
	- check periodically for deadlock
	- if detected, then can:
		- abort all D-lock processes
		- rollback D-lock processes (must be able to reverse actions)
		- abort D-lock processes one by one until deadlock broken
		- preempt resources one by one until deadlock broken (rollback)

Avoidance
	- conservative scheme, undercommits
	- only grant resource after verifying that there is some 
	  sequence of state transitions by which all processes can
	  execute
	- before first request, process must declare maximum claim 
	- safe state: if every process were to excercise its maximum
	  claim, there is some sequence by which these requests could
	  be granted that would not lead to deadlock
	- how to determine this? Banker's Algorithm