the ostrich algorithm

There is an old (and unfair to actual ostriches) image of an ostrich burying its head in the sand to pretend danger is not there. The ostrich algorithm is the tongue-in-cheek name for an operating system's strategy of doing exactly that with deadlock: pretend deadlocks never happen, take no special precautions at all, and if one does occur, leave it to the user or operator to notice and reboot or kill processes by hand.

It is not really an 'algorithm' but a deliberate non-strategy: no prevention rules, no avoidance bookkeeping, no detection sweeps, no automatic recovery. The system just allocates resources freely and hopes. The justification is a cost-benefit calculation. Deadlock prevention restricts how programs may run; avoidance demands maximum-need declarations and costly per-request safety checks; detection-and-recovery consumes CPU and may have to kill processes and lose work. If deadlocks are rare in practice, paying any of those costs all the time may be far more expensive than the occasional manual cleanup. Most general-purpose operating systems — including the mainstream UNIX, Linux, and Windows kernels for ordinary resource use — choose this path.

This is the honest, sometimes surprising punchline of the whole topic: the elegant banker's algorithm and the four-condition theory are mostly taught for understanding, while real systems usually IGNORE deadlock. That is an engineering judgment, not laziness — it trades a small risk of a rare hang against the constant overhead and rigidity of the alternatives. It is a poor choice where a hang is catastrophic (life-critical or hard-real-time systems), and it quietly relies on the fact that many deadlocks, when they do strike, are caused by application bugs the developers should fix anyway.