Monday, October 3, 1993
Today:
	Handling deadlocks (chapter 6)
-------------------------------------------------------------------------------
System contains a finite number of resources to be distributed among a
	number of competing processes
Resources partitioned into several types.  Each instance of a type is
	identical to other instances (e.g., CPU, CPU cycles, memory
	space, files, I/O devices)
Process system model: processes use resource in only the following sequence
	- Request (if requested resource is in use then process must
	  wait until resource can be acquired)
	- Use (Process can operate on the resource)
	- Release (Process releases the resource)
Deadlock:  A set of processes is in a deadlock state when every
	process in the set is waiting for an event that can be caused only by
	another process in the set.
-------------------------------------------------------------------------------
Example: gridlock
	what are resources?
-------------------------------------------------------------------------------
Strategies for dealing with deadlocks:
- Deadlock prevention
  Construct system in such a way that deadlock cannot happen
- Deadlock avoidance
  When deadlock could potentially occur, sidestep deadlock situation
- Deadlock detection/recovery
  When deadlock occurs take steps to remove deadlock situation (e.g.,
  roll back or terminate some processes)
- Ignore the problem altogether
  Maybe not such a bad engineering solution if deadlocks are rare
  (e.g., system crashes due to hardware errors, bugs, once a month but
  deadlock occurs only once every five years).  Disadvantage: offends
  programmer's sense of order.  Advantage:  solutions extract a high
  price---either performance or in limiting programming style (see later)
-------------------------------------------------------------------------------
Four necessary and sufficient deadlock conditions (must hold simultaneously)
- Mutual exclusion: at least one resource cannot be shared (used in a
  nonsharable mode).  Processes claim exclusive control of resources.
- Hold and wait: Processes hold resources already allocated to them
  while waiting for additional resources
- No preemption: Process keeps a resource granted to it until it
  voluntarily releases it
- Circular wait: Circular chain of processes exists in which each
  process holds one or more resources requested by the next process in
  the chain (implies hold and wait)
We will see that breaking any one of the conditions will prevent deadlock
-------------------------------------------------------------------------------
Resource allocation graph
	Process: circle
	Resource type: square
		Resource instance: dot within square
Process Pi, Resource Rj
	Arc from Pi to Rj (Pi-->Rj) is a request edge.  Pi requesting
		instance of resource type Rj
	Arc from Rj to Pi (Rj-->Pi) is a assignment edge.  One of
		instances of resource type Rj (specify which by
		drawing arc from dot) is assigned to process Pi
Example: processes A, B, C and resources R, S, T.  One instance of
each resource
	A requests R (granted)
	B requests S (granted)
	C requests T (granted)
	A requests S (wait)
	B requests T (wait)
	C requests R (deadlock)
How do we know that deadlock exists?  cycle
If each resource type has exactly one instance, cycle implies deadlock
has occurred.
If each resource has several instances, then cycle is necessary but
not sufficient condition.

Consider example from text:
	Processes P1, P2, P3, P4; Resources R1[2], R2[2]
	arcs P1->R1, R1->P2, R1->P3, P3->R2, R2->P1, R2->P4
	cycle exists
	note however that when P4 completes, P3 can continue, breaking
	deadlock  (same for P2)
General technique: reduction of graph
	if process' resource requests may be granted, remove arrows
	from and to that process.  (this is equivalent to that process
	completing and releasing its resources).  If a graph can be
	reduced by all of its processes then there is no deadlock.  If not,
	then the irreducible processes constitute the set of deadlocked
	processes in the graph
Book example above, remove R1->P2; R2->P4; then can remove R1->P3->R2;
and can remove R2->P1->R1.  No deadlock

Second book example:
	Processes P1, P2, P3; Resources R1[1], R2[2], R3[1]
	arcs P1->R1, R1->P2, P2->R2, R3->P3, R2->P1, R2->P2, P3->R2
Try reducing.  No reductions possible so deadlock involving P1, P2, P3

(Also works for single resource instance example)
-------------------------------------------------------------------------------
Next:
- deadlock prevention (ensuring that at least one of the four
necessary conditions cannot hold)
- deadlock avoidance (carefully allocate resources to avoid deadlock;
banker's algorithm)
- deadlock detection (algorithmetic means of detection)