The banker's algorithm is a deadlock-prevention method used in operating systems to decide whether a process can safely use resources without causing the system to freeze.
When multiple programs run at the same time, they often need the same resources—memory, disk access, printer connections, database locks. If Program A holds Resource 1 and waits for Resource 2, while Program B holds Resource 2 and waits for Resource 1, neither can proceed. The system is deadlocked. The banker's algorithm stops this before it happens by checking whether granting a resource request would leave the system in a safe state.
The name comes from banking: a banker doesn't lend out all available cash at once, even if customers request it. Instead, the banker keeps enough in reserve to handle all outstanding loan commitments. If a customer asks for money, the banker first checks: "If I give this person what they ask for, can I still meet everyone else's obligations?" Only if the answer is yes does the loan go through. Operating systems use the same logic with computing resources.
Key Takeaways
- The banker's algorithm prevents deadlock by checking whether granting a resource request would leave the system able to complete all running processes.
- The system tracks three pieces of information for each process: the maximum resources it might need, the resources it currently holds, and the resources still available.
- Before granting any resource request, the algorithm runs a safety check that simulates whether all processes could eventually finish if they received their remaining requests in some order.
- The algorithm works only when the maximum resource needs of each process are known in advance, which is why it is rarely used in modern operating systems.
How the algorithm tracks resource state
The banker's algorithm maintains three data structures for every resource type in the system. The Available vector shows how many units of each resource are currently free. The Maximum matrix records the total amount of each resource that each process might need over its lifetime. The Allocation matrix tracks how much of each resource each process is currently using.
From these three pieces, the system can calculate the Need matrix—the difference between what each process might still require and what it already holds. If Process 3 might need 10 units of Resource A total, and it currently holds 6, then its remaining need is 4. The algorithm uses this Need matrix to decide whether a request is safe to grant.
The safety check that decides whether to grant a request
When a process asks for resources, the algorithm does not when ready say yes or no. Instead, it performs a safety check: it temporarily assumes the request is granted, then asks "Can all processes now finish?" If the answer is yes, the request is safe and gets approved. If the answer is no, the request is denied and the process must wait.
The safety check works by finding a sequence in which all processes can complete. It looks for any process whose remaining needs can be satisfied with currently available resources. If it finds one, it assumes that process will run to completion, release all its resources, and adds those resources back to the available pool. Then it repeats: find another process that can now finish with the larger available pool. If it can build a sequence where every process eventually finishes, the system is in a safe state. If it gets stuck—no remaining process can finish with what is available—the system is unsafe, and the request must be denied.
A concrete example with three processes and two resources
Suppose the system has 10 units of Resource A and 5 units of Resource B. Three processes are running:
- Process 1: might need 7 A and 5 B total; currently holds 5 A and 2 B; still needs 2 A and 3 B.
- Process 2: might need 3 A and 2 B total; currently holds 2 A and 2 B; still needs 1 A and 0 B.
- Process 3: might need 9 A and 0 B total; currently holds 2 A and 0 B; still needs 7 A and 0 B.
Currently available: 1 A and 1 B. Process 2 asks for 1 more unit of A. The algorithm checks: if we grant this, Process 2 would have 3 A and 2 B—its maximum—and would finish, releasing those resources. Available would become 4 A and 3 B. Process 1 needs 2 A and 3 B; it could now finish and release 7 A and 5 B, making available 11 A and 8 B. Process 3 needs 7 A and 0 B; it could finish. All three processes have a completion order, so the system is safe. The request is granted.
If instead Process 3 had asked for 1 unit of A first, the algorithm would check: available would become 2 A and 1 B. Process 2 could still finish (needs 1 A, 0 B), releasing 3 A and 2 B for a total of 5 A and 3 B available. Process 1 needs 2 A and 3 B; it could finish. Process 3 needs 7 A and 0 B; with 5 A available, it cannot. No safe sequence exists, so the request would be denied.
Why modern systems rarely use the banker's algorithm
The banker's algorithm requires knowing the maximum resource needs of every process before it runs. In practice, most applications cannot predict their peak resource usage in advance. A web browser does not know how many file handles it will eventually need. A database does not know its maximum memory footprint until it starts running. Without accurate maximum values, the algorithm either overestimates (wasting resources by keeping too much in reserve) or underestimates (defeating the purpose of the check).
Modern operating systems instead use simpler deadlock-detection methods or allow deadlock to occur and recover from it. Linux and Windows do not implement the banker's algorithm in their core scheduling. It remains important in academic study of operating systems and in specialized real-time systems where maximum resource needs can be calculated, such as embedded systems or aerospace applications.
The difference between prevention, avoidance, and detection
The banker's algorithm is a deadlock avoidance strategy—it prevents deadlock from ever occurring by refusing requests that would lead to an unsafe state. This is different from deadlock prevention, which uses design rules to make deadlock mathematically impossible (for example, requiring all processes to request resources in the same order). It is also different from deadlock detection, which lets deadlock happen, then identifies and breaks it after the fact.
Avoidance sits between prevention and detection in terms of cost and complexity. Prevention is straightforward but restrictive. Detection is flexible but expensive to recover from. Avoidance tries to be selective—it allows many requests but blocks only those that would create risk. The banker's algorithm is the most well-known avoidance method, though its practical limitations have made it less common than the other two approaches.
Frequently Asked Questions
Does the banker's algorithm may provide the system will never deadlock?
Yes, if the maximum resource needs are known accurately and the algorithm is implemented correctly. By refusing any request that would move the system into an unsafe state, it mathematically ensures that all running processes can eventually complete. The catch is that the accuracy of the maximum-need estimates determines whether the may provide holds in practice.
What happens if a process asks for more resources than its declared maximum?
The request is denied. The algorithm assumes each process will never exceed its declared maximum. If a process tries to, the system treats it as an error. This is one reason the algorithm requires accurate maximum values—if they are too low, legitimate requests get blocked.
Can the banker's algorithm run on a single-core processor?
Yes. Deadlock can occur on single-core systems when one process holds a resource and waits for another resource held by a different process that cannot run until the first process releases its resource. The banker's algorithm prevents this by blocking the initial request. The number of processor cores does not change the logic.
Is the banker's algorithm used in databases?
Some database systems use similar logic to manage locks on rows and tables, but they typically do not use the banker's algorithm itself because they cannot predict lock needs in advance. Instead, they use deadlock detection—they allow lock cycles to form, then break them by rolling back one transaction and restarting it.