The Banker's Algorithm for Detecting/Preventing Deadlocks1

Banker's Algorithm for One Resource

This is modeled on the way a small town banker might deal with customers' lines of credit. In the course of conducting business, our banker would naturally observe that customers rarely draw their credit lines to their limits. This, of course, suggests the idea of extending more credit than the amount the banker actually has in her coffers2.

Suppose we start with the following situation

Customer Credit Used Credit Line
Andy 0 6
Barb 0 5
Marv 0 4
Sue 0 7
Funds Available 10
Max Commitment 22

Our banker has 10 credits to lend, but a possible liability of 22. Her job is to keep enough in reserve so that ultimately each customer can be satisfied over time: That is, that each customer will be able to access his full credit line, just not all at the same time. Suppose, after a while, the bank's credit line book shows

Customer Credit Used Credit Line
Andy 1 6
Barb 1 5
Marv 2 4
Sue 4 7
Funds Available 2
Max Commitment 22

Eight credits have been allocated to the various customers; two remain. The question then is: Does a way exist such that each customer can be satisfied? Can each be allowed their maximum credit line in some sequence? We presume that, once a customer has been allocated up to his limit, the banker can delay the others until that customer repays his loan, at which point the credits become available to the remaining customers. If we arrive at a state where no customer can get his maximum because not enough credits remain, then a deadlock could occur, because the first customer to ask to draw his credit to its maximum would be denied, and all would have to wait.

To determine whether such a sequence exists, the banker finds the customer closest to his limit: If the remaining credits will get him to that limit, The banker then assumes that that loan is repaid, and proceeds to the customer next closest to his limit, and so on. If all can be granted a full credit, the condition is safe.

In this case, Marv is closest to his limit: assume his loan is repaid. This frees up 4 credits. After Marv, Barb is closest to her limit (actually, she's tied with Sue, but it makes no difference) and 3 of the 4 freed from Marv could be used to award her maximum. Assume her loan is repaid; we have now freed 6 credits. Sue is next, and her situation is identical to Barb's, so assume her loan is repaid. We have freed enough credits (6) to grant Andy his limit; thus this state safe.

Suppose, however, that the banker proceeded to award Barb one more credit after the credit book arrived at the state immediately above:

Customer Credit Used Credit Line
Andy 1 6
Barb 2 5
Marv 2 4
Sue 4 7
Funds Available 1
Max Commitment 22

Now it's easy to see that the remaining credit could do no good toward getting anyone to their maximum.

So, to recap, the banker's algorithm looks at each request as it occurs, and tests if granting it will lead to a safe state. If not, the request is delayed. To test for a safe state, the banker checks to see if enough resources will remain after granting the request to satisfy the customer closest to his maximum. If so, that loan is assumed repaid, and the next customer checked, and so on. If all loans can be repaid, then the request leads to a safe state, and can be granted. In this case, we see that if Barb is awarded another credit, Marv, who is closest to his maximum, cannot be awarded enough credits, hence Barb's request can't be granted —it will lead to an unsafe state3.



Banker's Algorithm for Multiple Resources4

Suppose, for example, we have the following situation, where the first table represents resources assigned, and the second resources still required by five processes, A, B, C, D, and E.

Resources Assigned
Processes Tapes Plotters Printers Toasters
A 3 0 1 1
B 0 1 0 0
C 1 1 1 0
D 1 1 0 1
E 0 0 0 0
Total Existing 6 3 4 2
Total Claimed by Processes 5 3 2 2
Remaining Unclaimed 1 0 2 0

Resources Still Needed
Processes Tapes Plotters Printers Toasters
A 1 1 0 0
B 0 1 1 2
C 3 1 0 0
D 0 0 1 0
E 2 1 1 0

The vectors E, P and A represent Existing, Possessed and Available resources respectively: 

      E = (6, 3, 4, 2)
      P = (5, 3, 2, 2)
      A = (1, 0, 2, 0)
Notice that 
      A = E - P

Now, to state the algorithm more formally, but in essentially the same way as the example with Andy, Barb, Marv and Sue:

  1. Look for a row whose unmet needs don't exceed what's available, that is, a row where P <= A; if no such row exists, we are deadlocked because no process can acquire the resources it needs to run to completion. If there's more than one such row, just pick one.

  2. Assume that the process chosen in 1 acquires all the resources it needs and runs to completion, thereby releasing its resources. Mark that process as virtually terminated and add its resources to A.

  3. Repeat 1 and 2 until all processes are either virtually terminated (safe state), or a deadlock is detected (unsafe state).

Going thru this algorithm with the foregoing data, we see that process D's requirements are smaller than A, so we virtually terminate D and add its resources back into the available pool: 

      E = (6, 3, 4, 2)
      P = (5, 3, 2, 2) - (1, 1, 0, 1) = (4, 2, 2, 1)
      A = (1, 0, 2, 0) + (1, 1, 0, 1) = (2, 1, 2, 1)
Now, A's requirements are less than A, so do the same thing with A: 
      P = (4, 2, 2, 1) - (3, 0, 1, 1) = (1, 2, 1, 0)
      A = (2, 1, 2, 1) + (3, 0, 1, 1) = (5, 1, 3, 2)
At this point, we see that there are no remaining processes that can't be satisfied from available resources, so the illustrated state is safe.

Notes
  1. This is adapted from Operating Systems (Minix) by Andrew Tannenbaum (ISBN 0-13-637406-9).

  2. Which brings to mind the old ditty 
    	I've got sixpence,
	jolly, jolly sixpence.

	Tuppence to spend,
	and tuppence to lend,
	and tuppence to take home to my wife.

	Poor wife.
  3. In the real world, of course, Alan Greenspan would just print up some money and lend it to our banker at essentially zero interest, and Barb would get her cut without delay. Everybody would profit, no deadlock would ensue, and all would live happily ever after. In the O/S world, however, resources can't just be printed up and pressed into service willy-nilly.


  4. This is essentially the same as the explanation on pp. 261 - 263 of the textbook, but without most of the fancy mathematical notation.