the no-preemption condition

Imagine a public charging locker where, once you put your phone in and lock it, no attendant may open it to give the slot to someone in more of a hurry — only you can unlock it when you choose. The slot cannot be taken back by force. That 'no taking back' rule is the no-preemption condition: a resource held by a process cannot be forcibly reclaimed; it is released only when that process voluntarily gives it up.

This is the third of the four necessary conditions for deadlock. It matters because if the OS COULD snatch a held resource away from a blocked process and hand it to someone else, waiting chains could be broken on the spot and deadlock prevented. Some resources permit this: the CPU is routinely preempted by the scheduler, and memory pages can be preempted by swapping their contents out to disk and restoring them later. For such resources we can save and restore state cleanly, so preemption is safe. The deadlock-prevention idea is to make resources preemptible: when a process that holds some resources requests another that is unavailable, force it to release all it currently holds (its held resources are preempted), and let it restart later once it can get everything.

The honest catch is that many resources simply cannot be preempted without breaking correctness. You cannot yank a half-printed page back from a printer, nor revoke a lock protecting a half-finished update to shared data without leaving that data in a corrupt, inconsistent state. Preemption only works for resources whose state can be SAVED and faithfully RESTORED later (like CPU registers or memory pages). For everything else, preemption is not a real option, which is why no-preemption is so often the condition you cannot remove — and you must attack one of the other three instead.