An Operating Systems Vade Mecum

Advance-claim algorithm 135(3) The ith process can finish if all the previous processes do, because the sum of alltheir resources and the currently free resources can satisfy the entire claim of theith process.Informally, the state is safe because at the worst, we can avoid deadlock by blocking allnew requests except those made by the first process. When it finishes we will allow onlythe second to continue, and so forth. One hopes, of course, that such serialization willnot be necessary.Here is an example.Process Holding ClaimsA 4 6 B 2 7C 4 11 Unallocated 2A can certainly finish, because the 2 unallocated resources can be granted to it if necessaryto bring its holdings to the 6 that it claims. When it finishes, it will release all 6resources. We could then certainly finish B by applying 5 of those resources to bring itsholdings up to its claim of 7. When it terminates, it will release all 7, giving us 8 unallocatedresources. Those resources suffice to finish C. We have shown that {A, B, C} isasafe sequence, so the current state is safe. However, a very similar allocation state isunsafe:Process Holding ClaimsA 4 6 B 2 9 C4 11Unallocated 2A could finish as before, but we cannot guarantee that either B or C would finish becauseafter A’s termination, there are only 6 unallocated resources. We might be lucky,though, and B might finish without requesting its full claim. So an unsafe state does notnecessarily have a deadlock.Having established these concepts, we can define the advance-claim algorithm:Advance-claim algorithmNever allocate a request if it causes the currentallocation state to become unsafe.This algorithm is often called the banker’s algorithm.At first, this criterion appears expensive to evaluate. Whenever a process makes anew request, the resource manager must find a safe sequence under the assumption that