Operating Systems

================ Start Lecture #7 ================

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).

Recall the comparison made above between detecting deadlocks (with multi-unit resources) and the banker's algorithm

In the definition of a safe state no assumption is made about the running processes; that is, for a state to be safe termination must occur no matter what the processes do (providing the all terminate and to not exceed their claims). Making no assumption is the same as making the most pessimistic assumption.

Give an example of each of the four possibilities. A state that is

  1. Safe and deadlocked--not possible.

  2. Safe and not deadlocked--trivial (e.g., no arcs).

  3. Not safe and deadlocked--easy (any deadlocked state).

  4. Not safe and not deadlocked--interesting.

Is the figure on the right safe or not?

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

Example 2

A unsafe state with 22 units of one resource
processclaimcurrentmax need

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: A has claimed 3 units of resource 5, but there are only 2 units in the entire system. Change the problem by having B both claim and be allocated 1 unit of resource 5.

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


3.9: Summary