If we preempt a resource from a process, the process cannot continue with its…

One way deadlock prevention breaks the no-preemption condition is by allowing the operating system to forcibly take a resource away from a process that is holding it, rather than only allowing voluntary release. Because the process's internal execution context, its register values, in-flight computations, and assumptions about the data or resource it was using, was built around continuously holding that resource, simply pausing or removing the process is not enough once the resource is forcibly taken away, the process's progress since it last reached a known-consistent point can no longer be trusted.

So the operating system restores the process to the last state it is known to have been valid and consistent for, a previously recorded checkpoint or safe state, and lets the process resume its computation from that point onward. Only the work carried out after that checkpoint is discarded; everything before it remains intact, which is what distinguishes this response from simply discarding the process altogether.

• aborted or terminated: both end the process's execution outright and reclaim all of its resources permanently, there is no resumption at all, so neither matches an approach that lets the process continue after preemption.

• queued: places a process into a wait line while its own execution context is left untouched, waiting only for a resource or the CPU to free up, it does not address the fact that the process's in-progress state has already been invalidated by the forced preemption.

• rolled back: restores the process to a previously recorded safe state and lets it resume from there, which is exactly the standard response defined for resource preemption in deadlock prevention.