Operating Systems

Start Lecture #14

A manager can determine if a state is safe.

• Since the manager know all the claims, it can determine the maximum amount of additional resources each process can request.
• The manager knows how many units of each resource it has left.

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 maximum additional request for each resource type is less than what remains for that resource type.
   • If no such process can be found, then the state is not safe.
   • If such a P can be found, the banker (manager) knows that if it refuses all requests except those from P, then it will be able to satisfy all of P's requests. Why?
     Ans: Look at how P was chosen.
   
   
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

Consider the example shown in the table on the right.

A safe state with 22 units of one resource

process	initial claim	current alloc	max add'l
X	3	1	2
Y	11	5	6
Z	19	10	9
Total		16
Available		6

• One resource type R with 22 unit.
• Three processes X, Y, and Z with initial claims 3, 11, and 19 respectively.
• Currently the processes have 1, 5, and 10 units respectively.
• Hence the manager currently has 6 units left.
• Also note that the max additional needs for the processes are 2, 6, and 9 respectively.
• So the manager cannot assure (with its current remaining supply of 6 units) that Z can terminate. But that is not the question.
• This state is safe.
  1. Use 2 units to satisfy X; now the manager has 7 units.
  2. Use 6 units to satisfy Y; now the manager has 12 units.
  3. Use 9 units to satisfy Z; done!

Example 2

This example is a continuation of example 1 in which Z requested 2 units and the manager (foolishly?) granted the request.

An unsafe state with 22 units of one resource

process	initial claim	current alloc	max add'l
X	3	1	2
Y	11	5	6
Z	19	12	7
Total		18
Available		4

• Currently the processes have 1, 5, and 12 units respectively.
• The manager has 4 units.
• The max additional needs are 2, 6, and 7.
• This state is unsafe
  1. X is the only process whose maximum additional request can be satisfied at this point.
  2. So use 2 unit to satisfy X; now the manager has 5 units.
  3. Y needs 6 and Z needs 7 and we can't guarantee satisfying either request.
• Note that we were able to find a process (X) that can terminate, but then we were stuck. So it is not enough to find one process. We must find a sequence of all the processes.

Remark: An unsafe state is not necessarily a deadlocked state. Indeed, for many unsafe states, if the manager gets lucky all processes will terminate successfully. Processes that are not currently blocked can terminate (instead of requesting more resources up to their initial claim, which is the worst case and is the case the manager prepares for). A safe state means that the manager can guarantee that no deadlock will occur (even in the worst case in which processes request as much as permitted by their initial claims.)

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

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

In a little more detail the banker's algorithm is as follows.

• Before execution begins, ensure that the system is safe. That is, check that no process claims more than the manager has. If not, then the offending process is trying to claim more of some resource than exists in the system has and hence cannot be guaranteed to complete even if run by itself. You might say that it can become deadlocked all by itself. The only thing the manager can do is to refuse to acknowledge the existence of the offending process.
  
  
• When the manager receives a request, it pretends to grant it, and then checks if the resulting state is safe. If it is safe, the request is really granted; if it is not safe the process is blocked (that is, the request is held up).
  
  
• When a resource is returned, the manager (politely thanks the process and then) checks to see if the first pending requests can be granted (i.e., if the result would now be safe). If so the pending request is granted. Whether or not the request was granted, the manager checks to see if the next pending request can be granted, etc.

Homework: 16.

6.5.4 The Banker's Algorithm for Multiple Resources

At a high level the algorithm is identical to the one for a single resource type: Stay in safe states.

But what is a safe state in this new setting?

The same definition (if processes are run in a certain order they will all terminate).

Checking for safety is the same idea as above. The difference is that to tell if there are enough free resources for a processes to terminate, the manager must check that for all resource types, the number of free units is at least equal to the max additional need of the process.

Homework: Consider a system containing a total of 12 units of resource R and 24 units of resource S managed by the banker's algorithm. There are three processes P1, P2, and P3. P1's claim is 0 units of R and 12 units of S, written (0,12). P2's claim is (8,15). P3's claim is (8,20). Currently P1 has 4 units of S, P2 has 8 units of R, P3 has 8 units of S, and there are no outstanding requests.

1. What is the largest number of units of S that P1 can request at this point that the banker will grant?
2. If P2 instead of P1 makes the request, what is the largest number of units of S that the banker will grant?
3. If P3 instead of P1 or P2 makes the request, what is the largest number of units of S that the banker will grant?

Remark: Remind me to go over this one next time.

Limitations of the Banker's Algorithm

• Often users don't know the maximum requests a process will make. They can estimate conservatively (i.e., use big numbers for the claim) but then the manager becomes very conservative.
  
  
• New processes arriving cause a problem (but not so bad as Tanenbaum suggests).
  • The process's claim must be less than the total number of units of the resource in the system. If not, the process is not accepted by the manager.
  • Since the state without the new process is safe, so is the state with the new process! Just use the process order the banker had originally and put the new process at the end.
  • Insuring fairness (starvation freedom) needs a little more work, but isn't too hard either (once an hour stop taking new processes until all current processes finish).
  
  
• A resource can become unavailable (e.g., a CD-ROM drive might break). This can result in an unsafe state and deadlock.

Homework: 22, 25, and 30. There is an interesting typo in 22. 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.

6.7 Other Issues

6.7.2 Communication Deadlocks

We have mostly considered actually hardware resources such as printers, but have also considered more abstract resources such as semaphores.

There are other possibilities. For example a server often waits for a client to make a request. But if the request msg is lost the server is still waiting for the client and the client is waiting for the server to respond to the (lost) last request. Each will wait for the other forever, a deadlock.

A solution to this communication deadlock would be to use a timeout so that the client eventually determines that the msg was lost and sends another.

But it is not nearly that simple: The msg might have been greatly delayed and now the server will get two requests, which could be bad, and is likely to send two replies, which also might be bad.

This gives rise to the serious subject of communication protocols.

6.7.3 Livelock

Instead of blocking when a resource is not available, a process may (wait and then) try again to obtain it. Now assume process A has the printer, and B the CD-ROM, and each process wants the other resource as well. A will repeatedly request the CD-ROM and B will repeatedly request the printer. Neither can ever succeed since the other process holds the desired resource. Since no process is blocked, this is not technically deadlock, but a related concept called livelock.

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

6.8 Research on Deadlocks

6.9 Summary

Read.

Remark: Midterm covers up to here.