Friday, October 8, 1993

Announcement
- Working date for midterm: Monday, October 18, 1993 (through chapter 6)
- Friday October 15 class will be devoted to Question and Answer as prep.
- Instructor will be out of town on 10/18 so you should review
  material by 10/15
- TA has sent out test data (announced last time) and sample project
  run.  If you don't have email access, see him.
-------------------------------------------------------------------------------
Today: Deadlock avoidance and Deadlock detection
-------------------------------------------------------------------------------
General idea: require additional information about how resources will
be requested.  Use this information to determine whether to grant an
allocation request or to cause the requesting process to wait.

One such approach is used by Dijkstra's Banker's Algorithm

*Maximum need* for process declared by each process
*safe (resource allocation) state*: some way exists for OS to satisify
	all potential requests by running processes in some order
More formally, there exists a sequence of processes <P1, P2, ... Pn>
	such that for each Pi in the sequence, 1<=i<=n the resources that Pi
	can still request (i.e., maximum need - current need) can be satisfied
	by the currently available resources plus the resources held by all
	the Pj, j<i.
*unsafe state*: not safe
Note: if safe then no deadlock
      if deadlock then unsafe
      but can be unsafe without deadlock
so unsafe *may* lead to deadlock but not necessarily..  Unsafe only
implies that some unfortunate sequence of steps might lead to a deadlock.
Also, safe state can become unsafe...  All depends on process behavior
-------------------------------------------------------------------------------
Example of safe state

10 instances of resource, 3 processes.  Free: 3
		current		maximum		needs (max-current)
	p1	3		9		6
	p2	2		4		2
	p3	2		7		5
Is safe (grant p2, p3, p1)
can become unsafe: grant 2 more drives to p1 initially, no one can get
rest of maximum allocation (but note again not deadlocked and that
there are sequences that would get through ok)
-------------------------------------------------------------------------------
Basic notion of banker's algorithm:  don't grant a request if it would
cause state to become unsafe; force process to wait

Determine that state is safe by adding a "finish" column to the
"current", "maximum", and "needs" columns above.  Initialize all to
"false"

repeatedly cycle through list until either all "finish" entries are
"true" or until no further change is possible
	if finish[i] == false and needs[i] <= available
		finish[i] = true;
		available = available + current[i]
if all "finish" entries are "true" then the state is safe

Banker's algorithm takes an allocation request and
- verify that the request does not cause process to exceed declared
maximum (abort if not)
- verify that there are sufficient available resources to meet request
(block if not)
- verify that if the request were granted the resulting state would be
safe (block if not)

Deallocation of course requires reevaluation of blocked processes
(once again maintaining safe state)
===============================================================================
Deadlock detection: must (1) determine that deadlock has occurred and
(2) determine how to recover from deadlock

Deadlock detection (multiple instances of resource type) similar in
spirit to the graph reduction process described in earlier lecture.
Essentially examine the possible allocation sequence for processes
remaining to be completed

Keep track of (1) number of resources of each type *available* for
allocation; (2) number of each type *allocated* to each process; (3)
number of each type *requested* by each process.  Additionally keep a
vector of marks, one per process.

Initially all processes are unmarked.  Repeatedly go through process
list and find an unmarked process whose resource needs can be met
(e.g., requesti <= available).  Mark the process and add it's current
allocation into the available number).  Continue until all processes
are marked or until no further change possible.

If all processes are marked, no deadlock.  If some are still unmarked,
deadlock and those processes are involved.

Given m resources and n processes, algorithm is O(n*m^2)
-------------------------------------------------------------------------------
Single instance of resource type permits resource allocation graph to
be collapsed into a "wait for graph".  Edge from Pi-->Pj implies Pi
waiting for Pj to release a resource.  Essentially remove resource
nodes and collapse arcs.

Cycle in wait-for graph implies deadlock.  Finding cycle in graph is
O(n^2) for n processes.
-------------------------------------------------------------------------------
Recovery from deadlock
Process termination alternatives
	- abort all deadlocked processes
	- abort one process at a time until deadlock cycle eliminated.
	  Requires checking for deadlock after terminating each process.
	  Perhaps use "minimum cost" metric to decide which to
	  terminate first.  (e.g., process priority, process longevity
	  [long-lived process might be ready to terminate], resource
	  holdings, difference between current resource allocation and
	  maximum, as declared by process, interactive vs batch ...]
Resource preemption: successively preempt resources until deadlock
cycle is broken
	- selection of victim similar to above (cost factors); avoid
	  starvation
	- rollback of process to some consistent state necessary
	  (since it no longer has processes it once had)
-------------------------------------------------------------------------------