deadlock prevention
Recall that deadlock needs all four ingredients at once, like a fire needing fuel, heat, and oxygen. The simplest mindset is: just make sure one ingredient can NEVER appear, and deadlock becomes structurally impossible — not unlikely, but impossible. That is deadlock prevention: design the system so that at least one of the four necessary conditions can never hold, so by construction a deadlock cannot form. No checking at runtime, no detection, no recovery — the bad state is unreachable.
Concretely, prevention attacks one of the four conditions. Deny MUTUAL EXCLUSION where possible (make resources shareable, or use a spooler so processes never directly contend — though some resources are inherently non-shareable). Deny HOLD-AND-WAIT by requiring all-at-once allocation: a process must request everything it will need before starting, or must release all it holds before requesting more. Deny NO-PREEMPTION by allowing the system to forcibly reclaim a held resource (only safe for resources whose state can be saved and restored). Deny CIRCULAR WAIT by imposing a total ordering on resource types and requiring acquisition in increasing order — the most practical of the four, realized in code as lock ordering.
Prevention is robust and needs no advance knowledge of future requests, but it is honestly conservative: it forbids whole patterns of behavior, often hurting resource utilization and concurrency. All-at-once allocation makes processes hoard resources they are not yet using and can starve those needing many popular resources. Strict ordering can be awkward when natural code structure wants a different lock order. This is the central trade-off: prevention is safe and simple to reason about, but it pays for that safety by being pessimistic — which is why many systems prefer avoidance, detection, or simply ignoring the problem.
Lock-ordering prevention: number locks globally (mutex_1, mutex_2, mutex_3) and require every thread to acquire only in increasing index order. A thread holding mutex_2 may take mutex_3 but never mutex_1, so a circular wait can never form.
Imposing a total order on lock acquisition denies the circular-wait condition outright.
Prevention guarantees safety without runtime checks, but it is pessimistic: it forbids legal-looking behavior and tends to lower utilization and concurrency. Avoidance is the less restrictive cousin that uses future-need information.