Deadlocks:

In a multiprogramming environment, several processes may compete for a finite number of

resources. A process requests resources; if the resources are not available at that time, the process
enters a waiting state. Sometimes, a waiting process is never again able to change state, because the
resources it has requested are held by other waiting processes. This situation is called a deadlock.
We discussed this issue briefly in Chapter 5 in connection with semaphores. Perhaps the best
illustration of a deadlock can be drawn from a law passed by the Kansas legislature early in the 20th
century. It said, in part: “When two trains approach each other at a crossing, both shall come to a full
stop and neither shall start up again until the other has gone.” In this chapter, we describe methods
that an operating system can use to prevent or deal with deadlocks. Although some applications can
identify programs that may deadlock, operating systems typically do not provide deadlock-prevention
facilities, and it remains the responsibility of programmers to ensure that they design deadlock-free
programs.
Deadlock problems can only become more common, given current trends, including larger
numbers of processes, multithreaded programs, many more resources within a system, and an
emphasis on long-lived file and database servers rather than batch systems.

Resources:
In a computing system, processes require resources (e.g., CPU, memory, files, printers) to execute.
Resources can be classified into preemptable and non-preemptable resources based on whether they
can be forcibly taken from a process without causing issues.
Preemptable Resources
 These are resources that can be taken away from a process without causing failure.
 The system can safely reallocate these resources to another process.
Example:
 CPU Cycles: A running process can be interrupted and scheduled again later.
 Memory (RAM): The OS can swap out a process’s memory pages to disk and allocate
memory to another process.
Advantages of Preemptable Resources
✅Helps in deadlock recovery by allowing the system to take resources from one process and give
them to another.
✅ Allows for better resource management and efficient multitasking.
Challenges of Preemptable Resources
❌ Frequent preemption can lead to performance overhead (e.g., excessive context switching).
❌ Some resources, like cache memory, may suffer from performance degradation if frequently
swapped.
Non-Preemptable Resources
 These are resources that cannot be forcibly taken away from a process without causing
failure.
 The process must voluntarily release the resource before another process can use it.
Example:
Printers: If a document is being printed, preempting the printer would lead to a corrupted print job.
Files: If a process is writing to a file, forcefully stopping it can lead to data corruption.
Database Locks: A database transaction holding a lock cannot be interrupted without risking data
inconsistency.
Advantages of Non-Preemptable Resources
✅ Ensures data integrity and process stability.
✅ Reduces complexity in critical operations, such as printing or file handling.
Challenges of Non-Preemptable Resources
❌ Increases the risk of deadlocks because processes must wait for resources to be released.
❌ Requires careful resource management and deadlock handling techniques.

Conditions for resource deadlocks:

A deadlock situation can arise if the following four conditions hold
simultaneously in a system
1. Mutual exclusion. At least one resource must be held in a non-sharable mode; that
is, only one process at a time can use the resource. If another process requests that
resource, the requesting process must be delayed until the resource has been released.
2. Hold and wait. A process must be holding at least one resource and waiting to
acquire additional resources that are currently being held by other processes.
3. No Preemption. Resources cannot be preempted; that is, a resource can be released
only voluntarily by the process holding it, after that process has completed its task.
4. Circular wait. A set {P0, P1, ..., Pn} of waiting processes must exist such that P0 is
waiting for a resource held by P1, P1 is waiting for a resource held by
P2, ..., Pn-1 is waiting for a resource held by Pn, and Pn is waiting for a resource held
by P0.
We emphasize that all four conditions must hold for a deadlock to occur. The circular-
wait condition implies the hold-and-wait condition, so the four conditions are not
completely independent.
Ostrich algorithm:
The Ostrich Algorithm is a pragmatic approach to deadlock handling where the system
chooses to ignore the problem, assuming that deadlocks are rare and can be resolved by simply
restarting the system when necessary.
The name comes from the behaviour of an ostrich "burying its head in the sand" when facing
danger—ignoring the problem rather than actively solving it.
Deadlock Detection:
If a system does not employ either a deadlock-prevention or a deadlock avoidance algorithm, then a
deadlock situation may occur. In this environment, the system may provide:
•An algorithm that examines the state of the system to determine whether a deadlock has occurred
•An algorithm to recover from the deadlock

(a) Resource-allocation graph. (b) Corresponding wait-for graph.

In the following discussion, we elaborate on these two requirements as they pertain to systems with
only a single instance of each resource type, as well as to systems with several instances each resource
type. At this point, however, we note that a detection-and-recovery scheme requires overhead that
includes not only the run-time costs of maintaining the necessary information and executing the
detection algorithm but also the potential losses inherent in recovering from a deadlock.

Recovery from Deadlock:

When a detection algorithm determines that a deadlock exists, several alter natives are
available. One possibility is to inform the operator that a deadlock has occurred and to let the operator
deal with the deadlock manually. Another possibility is to let the system recover from the deadlock
automatically. There are two options for breaking a deadlock. One is simply to abort one or more
processes to break the circular wait. The other is to preempt some resources from one or more of the
deadlocked processes.
Process Termination
To eliminate deadlocks by aborting a process, we use one of two methods. In both methods, the
system reclaims all resources allocated to the terminated processes.
• Abort all deadlocked processes. This method clearly will break the deadlock cycle, but at great
expense. The deadlocked processes may have computed for a long time, and the results of these
partial computations must be discarded and probably will have to be recomputed later.
• Abort one process at a time until the deadlock cycle is eliminated.This
methodincursconsiderableoverhead,sinceaftereachprocessisaborted,a deadlock-detection algorithm
must be invoked to determine whether any processes are still deadlocked.

Deadlock avoidance:
Requires that the operating system be given additional information in advance concerning which
resources a process will request and use during its lifetime. With this additional knowledge, the
operating system can decide for each request whether or not the process should wait. To decide
whether the current request can be satisfied or must be delayed, the system must consider the
resources currently available, the resources currently allocated to each process, and the future requests
and releases of each process.
Deadlock Prevention:
Deadlock prevention provides a set of methods to ensure that at least one of the necessary conditions
for deadlock (Mutual Exclusion, Hold and Wait, No Preemption, and Circular Wait) cannot hold.
These methods prevent deadlocks by constraining how resource requests are made.

1. Mutual Exclusion
 The mutual exclusion condition must hold, meaning that at least one resource must be non-
sharable.
 Sharable resources, in contrast, do not require mutually exclusive access and thus cannot be
involved in a deadlock.
Example:
 Read-only files are sharable resources because multiple processes can access them
simultaneously.
 A process never needs to wait for a sharable resource.
 However, in general, we cannot prevent deadlocks by denying the mutual exclusion
condition because some resources are intrinsically non-sharable.

2. Hold and Wait

To ensure that the hold-and-wait condition never occurs, we must guarantee that whenever a
process requests a resource, it does not hold any other resources.
Protocol:
Each process must request and be allocated all its required resources before it begins execution.
This can be implemented by requiring that system calls requesting resources for a process precede
all other system calls.
3.No Preemption:
 To prevent deadlocks, the no preemption condition must be eliminated.
 This can be done by allowing the system to preempt (forcefully take away) resources from
a process when necessary.
Strategy:
 If a process holding some resources requests another resource that is unavailable, all its
currently held resources are released.
 The process is then restarted only when it can acquire all the necessary resources at once.
Example:
 In a CPU scheduling system, the CPU can be preempted from a running process and
assigned to another process without causing failure.
 Similarly, in a memory management system, pages can be swapped out and reassigned as
needed.
4.Circular Wait:
The fourth and final condition for deadlocks is the circular-wait condition. One way to ensure that this
condition never holds is to impose a total ordering of all resource types and to require that each
process requests resources in an increasing order of enumeration
Strategy:
 Assign a unique numerical order to all resource types.
 A process can only request resources in increasing order of these numbers.
 If a process requests a resource that is lower in the order than one it already holds, the
request is denied.
Example:
Suppose we assign numbers to resources as follows:
 Printer (1)
 Scanner (2)
 Hard Disk (3)
A process holding a scanner (2) cannot request a printer (1), ensuring no circular wait occurs.