Operating Systems

================ Start Lecture #13 ================

3.5.2: Safe States

Avoiding deadlocks given some extra knowledge.

Definition: A state is safe if there is an ordering of the processes such that: if the processes are run in this order, they will all terminate (assuming none exceeds its claim).

Give an example of all four possibilities. A state that is

  1. Safe and deadlocked--not possible
  2. Safe and not deadlocked
  3. Not safe and deadlocked
  4. Not safe and not deadlocked--interesting

A manager can determine if a state is safe.

The manager then follows the following procedure, which is part of Banker's Algorithms discovered by Dijkstra, to determine if the state is safe.

  1. If there are no processes remaining, the state is safe.

  2. Seek a process P whose max additional requests is less than what remains (for each resource type).
  3. The banker now pretends that P has terminated (since the banker knows that it can guarantee this will happen). Hence the banker pretends that all of P's currently held resources are returned. This makes the banker richer and hence perhaps a process that was not eligible to be chosen as P previously, can now be chosen.

  4. Repeat these steps.

Example 1

A safe state with 22 units of one resource
processclaimcurrentmax need
X312
Y1156
Z19109
Total16
Available6

Example 2

A unsafe state with 22 units of one resource
processclaimcurrentmax need
X312
Y1156
Z19127
Total18
Available4

Start with example 1 and assume that Z now requests 2 units and we grant them.

Remark: An unsafe state is not necessarily a deadlocked state. Indeed, if one gets lucky all processes may terminate successfully. A safe state means that the manager can guarantee that no deadlock will occur.

3.5.3: The Banker's Algorithm (Dijkstra) for a Single Resource

The algorithm is simple: Stay in safe states. Initially, we assume all the processes are present before execution begins and that all claims are given before execution begins. We will relax these assumptions very soon.

Homework: 13.

3.5.4: The Banker's Algorithm for Multiple Resources

At a high level the algorithm is identical: Stay in safe states.

Limitations of the banker's algorithm

Homework: 21, 27, and 20. There is an interesting typo in 20 (2nd edition of book): A has claimed 3 units of resource 5, but there are only 2 units in the entire system. Change A's claim to 2.

3.7: Other Issues

3.7.1: Two-phase locking

This is covered (MUCH better) in a database text. We will skip it.

3.7.2: Non-resource deadlocks

You can get deadlock from semaphores as well as resources. This is trivial. Semaphores can be considered resources. P(S) is request S and V(S) is release S. The manager is the module implementing P and V. When the manager returns from P(S), it has granted the resource S.

3.7.3: Starvation

As usual FCFS is a good cure. Often this is done by priority aging and picking the highest priority process to get the resource. Also can periodically stop accepting new processes until all old ones get their resources.

3.8: Research on Deadlocks

Skipped.

3.9: Summary

Read.