hold and wait
Picture someone making a sandwich who grabs the bread first, then stands at the fridge waiting for someone else to finish with the cheese — all while still clutching the bread so no one else can make toast. They are HOLDING one thing and WAITING for another at the same time. That habit, in a computer, is the hold-and-wait condition: a process keeps the resources it already owns even while it sits blocked waiting to acquire more.
Precisely, hold-and-wait is the second of the four necessary conditions for deadlock. It holds when a process is allowed to request new resources while it is still holding resources allocated to it earlier. This is what lets waiting chains form: because each process refuses to give up what it has, the things it holds remain unavailable to everyone else even as it idles. You can deny this condition with a protocol that forbids partial holding. The simplest is ALL-AT-ONCE allocation: a process must request EVERY resource it will ever need in one atomic step, before it starts, and gets either all of them or none. Then it never holds some while waiting for others.
Denying hold-and-wait does prevent deadlock, but it is honestly costly. All-at-once allocation forces a process to grab resources long before it actually uses them, so utilization drops (a printer reserved at startup sits idle for an hour). It can also cause STARVATION: a process needing several popular resources may wait indefinitely because they are rarely all free at the same instant. An alternative — release everything before requesting again — is awkward when a process needs to keep some state locked. This is why hold-and-wait prevention is real but rarely the chosen cure in general-purpose systems.
Deadlock-prone: lock(A); ...; lock(B). Hold-and-wait denied (all-at-once): lock_all(A, B) which blocks until BOTH are free and grants them together, so the process never holds A while merely waiting for B.
Acquiring resources one at a time enables hold-and-wait; acquiring them all together denies it.
All-at-once allocation truly prevents deadlock but wastes resources (held long before use) and can cause starvation when several popular resources are seldom all free at once.