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.
If there are no processes remaining, the state is
- 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
- 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.
Ans: Look at how P was chosen.
- 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
- Repeat these steps.
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|
- One resource type R with 22 unit.
- Three processes X, Y, and Z with initial claims 3, 11, and 19
- 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.
- Use 2 units to satisfy X; now the manager has 7 units.
- Use 6 units to satisfy Y; now the manager has 12 units.
- Use 9 units to satisfy Z; done!
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|
- 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
- X is the only process whose maximum additional request can
be satisfied at this point.
- So use 2 unit to satisfy X; now the manager has 5 units.
- Y needs 6 and Z needs 7 and we can't guarantee satisfying
- 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
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
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
- 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.
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
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.
- What is the largest number of units of S that P1 can request
at this point that the banker will grant?
- If P2 instead of P1 makes the request, what is the largest
number of units of S that the banker will grant?
- 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
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
- 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
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
6.7 Other Issues
6.7.1 Two-phase locking
This is covered (MUCH better) in a database text.
We will skip it.
6.7.2 Communication Deadlocks
We have mostly considered actually hardware resources such as
printers, but have also considered more abstract resources such as
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.
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
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
Neither can ever succeed since the other process holds the desired
Since no process is blocked, this is not technically deadlock, but a
related concept called livelock.
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
Remark: Midterm covers up to here.