1. Introduction
In the previous sections, we studied the first two necessary conditions for deadlock:
Mutual Exclusion
Hold and Wait
We now move to the third necessary condition:
No Preemption
This condition explains why processes can continue holding resources indefinitely, even when other processes are waiting for them.
The inability of the operating system to forcibly reclaim certain resources is one of the primary reasons deadlocks can persist once they occur.
Without the No Preemption condition, many deadlocks could be resolved simply by taking resources away from one process and assigning them to another. However, for many resources, such forced removal is either unsafe or impossible.
Understanding No Preemption is essential because it highlights the limitations of resource management and explains why deadlock recovery is often difficult and expensive.
2. Definition of No Preemption
The No Preemption condition states:
Resources cannot be forcibly taken away from a process. A resource can only be released voluntarily by the process holding it after the process completes its use of that resource.
In simpler terms:
A process acquires a resource
The resource becomes owned by that process
The operating system cannot arbitrarily remove it
The process decides when to release it
Until the resource is released:
Other Processes Must Wait
This creates the possibility of indefinite blocking.
3. Understanding the Core Idea
Consider the following situation:
P1 Holds Printer
and:
P2 Requests Printer
If resource preemption were allowed:
OS Takes Printer From P1
and assigns it to:
P2
However, for many resources this is unsafe.
Imagine that:
P1 Printing Document
and the printer is removed halfway through printing.
Possible consequences:
Incomplete output
Corrupted document
Inconsistent printer state
Therefore:
Printer Cannot Be Safely Reclaimed
The operating system must wait until P1 voluntarily releases the printer.
4. Why Some Resources Cannot Be Preempted
Many resources maintain internal execution state.
During operation:
Resource State Changes Continuously
If such a resource is interrupted unexpectedly:
Partial work may be lost
Data corruption may occur
Device state may become inconsistent
Recovery may be impossible
Because of these risks:
Forced Resource Removal Is Unsafe
for many real-world resources.
5. Examples of No Preemption
5.1 Printer
Suppose a process is printing a report.
Current situation:
Page 1 Printed
Page 2 Printing
Page 3 Pending
If the OS suddenly removes printer access:
Document Becomes Incomplete
Output may be corrupted.
Therefore:
Printer Is Non-Preemptable
5.2 File Writing
Consider a process updating a file.
Example:
Writing Data To Disk
If interrupted midway:
File May Be Partially Updated
Possible consequences:
Corrupted file
Missing records
Invalid metadata
Therefore:
File Write Locks Are Usually Non-Preemptable
5.3 Database Transactions
Database systems require consistency.
Example:
Transfer ₹1000
From Account A
To Account B
Execution:
Step 1:
Deduct From A
Step 2:
Add To B
If interrupted after Step 1:
Money Disappears
The database becomes inconsistent.
Therefore:
Transaction Locks Must Remain Protected
until completion.
5.4 Network Communication
Consider:
Active Network Session
If resources are removed abruptly:
Messages may be lost
Connections may fail
Protocol state may break
Thus:
Communication Resources Often Resist Preemption
6. Preemptable vs Non-Preemptable Resources
Understanding this distinction is extremely important.
6.1 Preemptable Resources
These resources can be temporarily removed and later restored without damaging system correctness.
Examples:
CPU
Virtual Memory
Memory Pages
Processor Registers
The operating system can:
Save State
Reassign Resource
Restore State Later
Therefore these resources are:
Preemptable
Example: CPU
The scheduler can interrupt a process.
Save PCB
Later:
Resume Execution
No corruption occurs.
6.2 Non-Preemptable Resources
These resources cannot be safely reclaimed during use.
Examples:
Printers
Scanners
File Locks
Database Locks
Tape Drives
Active I/O Devices
Such resources contribute significantly to deadlock formation.
Resource Must Be Released Voluntarily
7. How No Preemption Leads to Deadlock
Consider two resources:
Resource A
Resource B
and two processes:
P1
P2
Current situation:
P1 Holds A
P2 Holds B
Later:
P1 Waiting For B
P2 Waiting For A
A deadlock has formed.
If resource preemption were possible:
Take A From P1
or
Take B From P2
The deadlock could be broken.
However:
Resources Cannot Be Reclaimed
Therefore:
Processes Continue Waiting Forever
Deadlock persists.
8. Operating System Perspective
The operating system must preserve:
Correctness
Operations Must Complete Properly
Consistency
System State Must Remain Valid
Device Integrity
Hardware State Must Not Be Corrupted
Data Safety
Information Must Not Be Lost
Because of these requirements:
OS Cannot Randomly Revoke Resources
This limitation directly creates the No Preemption condition.
9. Can Preemption Be Introduced?
In some advanced systems:
Limited Preemption
is possible.
Techniques include:
Process Suspension
Checkpointing
Transaction Rollback
Resource Reallocation
The operating system may:
Save Process State
then:
Reclaim Resources
and later:
Restart Process
However:
Implementation is complex
Overhead is high
Not all resources support rollback
Therefore:
Practical Use Is Limited
10. Deadlock Prevention Strategy
One common prevention technique attempts to eliminate No Preemption.
Rule:
If a process requests a resource that cannot be immediately allocated, it must release all currently held resources.
Example:
Current situation:
P1 Holds A
Requests:
Resource B
Instead of waiting:
Release A
then:
Request B Later
Since resources can be reclaimed:
No Preemption Condition Broken
Deadlock becomes impossible.
11. Problems with Forced Preemption
Although deadlock risk decreases, several new challenges appear.
11.1 Rollback Overhead
Processes may need to restart.
Work Lost
and must be repeated.
11.2 Wasted Computation
Previously completed execution may become useless.
Example:
90% Complete
then rollback occurs.
Most work is lost.
11.3 Starvation Risk
A process may repeatedly lose resources.
Acquire Resource
Resource Reclaimed
Repeatedly.
The process may never finish.
11.4 Reduced Performance
Frequent rollbacks and reallocations increase overhead.
Consequences:
Lower throughput
Higher waiting times
Increased CPU overhead
System Efficiency Decreases
12. Real-World Analogy
Imagine a speaker giving a presentation.
The speaker currently holds:
Microphone
Another speaker wants it.
The organizer generally cannot:
Snatch Microphone Mid-Sentence
Doing so would:
Interrupt communication
Create confusion
Disrupt the event
Instead:
Current Speaker Finishes
and voluntarily returns the microphone.
This is precisely the idea behind:
No Preemption
13. Relationship with Other Deadlock Conditions
No Preemption alone does not create deadlock.
Similarly:
Mutual Exclusion Alone
does not create deadlock.
Hold and Wait Alone
does not create deadlock.
Deadlock occurs only when all necessary conditions coexist.
Combined Effect
Mutual Exclusion
creates exclusive ownership.
Hold and Wait
creates dependency chains.
No Preemption
prevents resource recovery.
Circular Wait
creates dependency cycles.
Together:
Deadlock Becomes Possible
Key Insight
No Preemption is the condition that allows blocked processes to continue holding resources indefinitely.
Without it:
OS Could Reclaim Resources
and many deadlocks could be resolved automatically.
Because many real-world resources cannot be safely preempted, operating systems must tolerate this condition and use other techniques such as deadlock prevention, avoidance, detection, and recovery.