UNIT - II

CPU Scheduling - Scheduling Criteria, Scheduling Algorithms, Multiple -Processor Scheduling.

System call interface for process management-fork, exit, wait, waitpid, exec.

Deadlocks - System Model, Deadlocks Characterization, Methods for Handling Deadlocks, Deadlock
Prevention, Deadlock Avoidance, Deadlock Detection, and Recovery from Deadlock.

CPU SCHEDULING
CPU scheduling is the basis of Multiprogrammed operating systems. By switching the CPU
among processes, the operating system can make the computer more productive.
● In a single-processor system, only one process can run at a time. Others must wait until the

CPU is free and can be rescheduled.

● The CPU will sit idle and wait for a process that needs an I/O operation to complete. If
the I/O operation completes then only the CPU will start executing the process. A lot of
CPU time has been wasted with this procedure.
● The objective of multiprogramming is to have some process running at all times to
maximize CPU utilization.
● When several processes are in main memory, if one process is waiting for I/O then the
operating system takes the CPU away from that process and gives the CPU to another
process. Hence there will be no wastage of CPU time.
Concepts of CPU Scheduling
1. CPU–I/O Burst Cycle
2. CPU Scheduler
3. Preemptive Scheduling
4. Dispatcher
CPU–I/O Burst Cycle
Process execution consists of a cycle of CPU execution and I/O wait.
● Process execution begins with a CPU burst. That is followed by an I/O burst. Processes
alternate between these two states.
● The final CPU burst ends with a system request to terminate execution.
● Hence the First cycle and Last cycle of execution must be CPU burst.

CPU Scheduler
Whenever the CPU becomes idle, the operating system must select one of the processes in the
ready queue to be executed. The selection process is carried out by the Short-Term
Scheduler or CPU scheduler.

Preemptive Scheduling
CPU-scheduling decisions may take place under the following four cases:
1. When a process switches from the running state to the waiting state.
Example: as the result of an I/O request or an invocation of wait( ) for the termination of
a child process.
2. When a process switches from the running state to the ready
state. Example: when an interrupt occurs
3. When a process switches from the waiting state to the ready
state. Example: at completion of I/O.
4. When a process terminates.

For situations 2 and 4 are considered as Preemptive scheduling situations. Mach OS X,

WINDOWS 95 and all subsequent versions of WINDOWS are using Preemptive scheduling.
 Dispatcher
The dispatcher is the module that gives control of the CPU to the process selected by
the short-term scheduler. Dispatcher function involves:
1. Switching context
2. Switching to user mode
3. Jumping to the proper location in the user program to restart that program.
The dispatcher should be as fast as possible, since it is invoked during every process switch.
The time it takes for the dispatcher to stop one process and start another process running is
known as the Dispatch Latency.

SCHEDULING CRITERIA
Different CPU-scheduling algorithms have different properties and the choice of a particular
algorithm may favor one class of processes over another.
Many criteria have been suggested for comparing CPU-scheduling algorithms:

● CPU utilization: CPU must be kept as busy as possible. CPU utilization can range from
0 to 100 percent. In a real system, it should range from 40 to 90 percent.
● Throughput: The number of processes that are completed per time unit.
● Turn-Around Time: It is the interval from the time of submission of a process to the
time of completion. Turnaround time is the sum of the periods spent waiting to get into
memory, waiting in the ready queue, executing on the CPU and doing I/O.
● Waiting time: It is the amount of time that a process spends waiting in the ready queue.

● Response time: It is the time from the submission of a request until the first response is
produced. Interactive systems use response time as its measure.
Note: It is desirable to maximize CPU utilization and Throughput and to minimize Turn-
Around Time, Waiting time and Response time.
CPU SCHEDULING ALGORITHMS
CPU scheduling deals with the problem of deciding which of the processes in the ready
queue is to be allocated to the CPU. Different CPU-scheduling algorithms are:
1. First-Come, First-Served Scheduling (FCFS)

2. Shortest-Job-First Scheduling (SJF)

3. Priority Scheduling

4. Round Robin Scheduling

5. Multilevel Queue Scheduling

6. Multilevel Feedback Queue Scheduling

Gantt Chart is a bar chart that is used to illustrate a particular schedule including the start
and finish times of each of the participating processes.
First-Come, First-Served Scheduling (FCFS)
In FCFS, the process that requests the CPU first is allocated the CPU first.
● FCFS scheduling algorithm is Non-preemptive.
● Once the CPU has been allocated to a process, it keeps the CPU until it releases the CPU.
● FCFS can be implemented by using FIFO queues.
● When a process enters the ready queue, its PCB is linked onto the tail of the queue.
● When the CPU is free, it is allocated to the process at the head of the queue.

● The running process is then removed from the queue.

Example:1 Consider the following set of processes that arrive at time 0. The processes are
arrived at in the order P1, P2, P3, with the length of the CPU burst given in milliseconds.

Process Burst Time

P1 24
P2 3
P3 3
Gantt Chart for FCFS is:

The average waiting time under the FCFS policy is often quite long.
● The waiting time is 0 milliseconds for process P1, 24 milliseconds for process P2 and
27 milliseconds for process P3.
● Thus, the average waiting time is (0 + 24 + 27)/3 = 17 milliseconds.
Convoy Effect in FCFS
Convoy effect means, when a big process is executing in CPU, all the smaller processes must
have to wait until the big process execution completes. This will affect the performance of
the system.
Example:2 Let us consider the same example above but with the processes arriving in the
order P2, P3, P1.

The processes coming at P2, P3, P1 the average waiting time (6 + 0 + 3)/3 = 3 milliseconds
whereas the processes come in the order P1, P2, P3 the average waiting time is 17
milliseconds. Disadvantage of FCFS:
FCFS scheduling algorithm is Non-preemptive, it allows one process to keep CPU for a long
time. Hence it is not suitable for time sharing systems.

Shortest-Job-First Scheduling (SJF)

The SJF algorithm is defined as “when the CPU is available, it is assigned to the process that
has the smallest next CPU burst”. If the next CPU bursts of two processes are the same,
FCFS scheduling is used between two processes.
SJF is also called the Shortest-Next CPU-Burst algorithm, because scheduling depends on
the length of the next CPU burst of a process, rather than its total length.

Example: Consider the following processes and CPU burst in milliseconds:

Process Burst Time

P1 6
P2 8
P3 7
P4 3
 Gantt Chart of SJF algorithm:

Waiting Time for Processes:

Process Burst Time (ms) Waiting Time
P1 6 3
P2 8 16
P3 7 9
P4 3 0
Average Waiting Time 7 ms
● By looking at the above table the average waiting time by using SJF algorithm is 7ms.
● SJF gives the minimum average waiting time for a given set of processes. SJF is optimal.
● The average waiting time decreases because moving a short process before a long process
decreases the waiting time of the short process more than it increases the waiting time of
the long process.

Difficulty with SJF

The difficulty with the SJF algorithm is “knowing the length of the next CPU request”. With
Short-Term Scheduling, there is no way to know the length of the next CPU burst. It is not
implemented practically.

Solution for the difficulty

One approach to this problem is to try to approximate SJF scheduling.
● We may not know the length of the next CPU burst, but we may be able to predict its
value. We expect that the next CPU burst will be similar in length to the previous
ones.
● By computing an approximation of the length of the next CPU burst, we can pick
the process with the shortest predicted CPU burst.
● The next CPU burst is generally predicted as an Exponential Average of the
measured lengths of previous CPU bursts.
The following formula defines the Exponential average:

tn be the length of the nth CPU burst (i.e. contains the most recent information).
stores the past history.
be our predicted value for the next CPU burst.
α controls the relative weight of recent and past history in our prediction (0 ≤ α ≤1)
● If α=0, then , recent history has no effect

● If α=1 then , only the most recent CPU burst matters.

● If α = 1/2, so recent history and past history are equally weighted.

Shortest Remaining Time First Scheduling (SRTF)

SRTF is the preemptive SJF algorithm.
● A new process arrives at the ready queue, while a previous process is still executing

● The next CPU burst of the newly arrived process may be shorter than the currently
executing process.
● SRTF will preempt the currently executing process and execute the shortest job.
Consider the four processes with arrival times and burst times in milliseconds:
Process Arrival time Burst Time (ms)
P1 0 8
P2 1 4
P3 2 9
P4 3 5
Gantt Chart for SRTF

● Process P1 is started at time 0, since it is the only process in the queue.

● Process P2 arrives at time 1. The remaining time for process P1 (7 milliseconds) is larger
than the time required by process P2 (4 milliseconds), so process P1 is preempted and
process P2 is scheduled.
● The average waiting time = 26/4 = 6.5 milliseconds.
● .
 Priority Scheduling
A priority is associated with each process and the CPU is allocated to the process with the
highest priority. Equal-priority processes are scheduled in FCFS order.
● An SJF algorithm is a special kind of priority scheduling algorithm where small
CPU bursts will have higher priority.
● Priorities can be defined based on time limits, memory requirements, the number of
open files etc.
Example: Consider the following processes with CPU burst and Priorities. All the processes
arrive at time t=0 in the same order. Low numbers are having higher priority.
Process Burst time (ms) Priority
P1 10 3
P2 1 1
P3 2 4
P4 1 5
P5 5 2
Gantt chart for Priority Scheduling:

Process Burst time (ms) Waiting Time

P1 10 6
P2 1 0
P3 2 16
P4 1 18
P5 5 1
Average Waiting Time 8.2 ms
Priority scheduling can be either Preemptive or Non-preemptive.
A Preemptive Priority Scheduling algorithm will preempt the CPU if the priority of the
newly arrived process is higher than the priority of the currently running process.

Problem: Starvation or Indefinite Blocking

● In priority Scheduling when there is a continuous flow of higher priority processes to the
readyqueue then all the lower priority processes must have to wait for the CPU until all
the higher priority processes execution completes.
● This leads to lower priority processes blocked from getting CPU for a long period of time.
This situation is called Starvation or Indefinite blocking.
● In the worst case indefinite blocking may take years to execute the process.
Solution: Aging
Aging involves gradually increasing the priority of processes that wait in the system for a
long time.

Round-Robin Scheduling (RR)

Round-Robin (RR) scheduling algorithm is designed especially for Time Sharing systems.
● RR is similar to FCFS scheduling, but preemption is added to enable the system to switch
between processes.
● A small unit of time called a Time Quantum or Time Slice is defined. A time quantum is
generally from 10 to 100 milliseconds in length.
● The ready queue is treated as a Circular queue. New processes are added to the tail
of the ready queue.
● The CPU scheduler goes around the ready queue by allocating the CPU to each
process for a time interval of up to 1 time quantum and dispatches the process.
● If a process CPU burst exceeds 1 time quantum, that process is preempted and is put
back in the ready queue.
In RR scheduling one of two things will then happen.
1. The process may have a CPU burst of less than 1 time quantum. The process itself will
release the CPU voluntarily. The scheduler will then proceed to the next process in the
ready queue.
2. If the CPU burst of the currently running process is longer than 1 time quantum, the timer
will go off and will cause an interrupt to the operating system. A context switch will be
executed and the process will be put at the tail of the ready queue. The CPU scheduler
will then select the next process in the ready queue.
Consider the following set of processes that arrive at time 0 and the processes are arrived at in
the order P1, P2, P3 and Time Quanta=4.
 Process Burst Time
P1 24

P2 3
P3 3
Gantt chart of Round Robin Scheduling

● If we use a time quantum of 4 milliseconds, then process P1 gets the first 4 milliseconds.
● Since it requires another 20 milliseconds, it is preempted after the first quantum and
the CPU is given to the next process in the queue, process P2.
● CPU burst of Process P2 is 3, so it does not need 4 milliseconds then it quits before
its time quantum expires. The CPU is then given to the next process P3.
● Once each process has received 1 time quantum, the CPU is returned to process P1 for an
additional time quantum.

The average waiting time under the RR policy is often long.

● P1 waits for 6 milliseconds (10 - 4), P2 waits for 4 milliseconds and P3 waits for 7
milliseconds. Thus, the average waiting time is 17/3 = 5.66 milliseconds.

The performance of the RR algorithm depends on the size of the Time Quantum.
● If the time quantum is extremely large, the RR policy is the same as the FCFS policy.
● If the time quantum is extremely small (i.e. 1 millisecond) the RR approach can result in
a large number of context switches.
● The time taken for context switch value should be a small fraction of Time quanta
then the performance of the RR will be increased.
Note: A rule of thumb is that 80 percent of the CPU bursts should be shorter than the time
quantum.
 Multi-Level Queue Scheduling (MLQ)
In the Multilevel Queue Scheduling algorithm the processes are classified into different
groups.
● A Multilevel queue scheduling partitions the ready queue into several separate queues.
● The processes are permanently assigned to one queue based on memory size,
process priority or process type. Each queue has its own scheduling algorithm.
Example: Foreground processes have highest priority over background processes and these
processes have different response times hence it needs different scheduling.

The above figure shows Multi-level queue scheduling algorithm with five queues, listed
below in order of priority:
1. System processes
2. Interactive processes
3. Interactive editing processes
4. Batch processes
5. Student processes

Each queue has absolute priority over lower-priority queues.

● No lower level queue processes will start executing unless all the processes in the higher
level queue are empty.
Example: The interactive processes start executing only when all the processes in the
system queue are empty.
● If a lower priority process is executing and a higher priority process enters into the queue
then a lower priority process will be preempted and starts executing a higher priority
process.
Example: If a system process entered the ready queue while an interactive process was
running, the interactive process would be preempted.
 Disadvantage: Starvation of Lower level queue
The multilevel queue scheduling algorithm is inflexible.
● The processes are permanently assigned to a queue when they enter the system.
Processes are not allowed to move from one queue to another queue.
● There is a chance that lower level queues will be in starvation because unless the
higher level queues are empty no lower level queues will be executing.
● If at any instant of time if there is a process in higher priority queue then there is
no chance that lower level process can be executed eternally.
Multilevel Feedback Queue Scheduling is used to overcome the problem of Multi-level queue
scheduling.
Multilevel Feedback Queue Scheduling (MLFQ)
Multilevel feedback queue scheduling algorithm allows a process to move between queues.
● Processes are separated according to the characteristics of their CPU bursts.
● If a process uses too much CPU time, it will be moved to a lower-priority queue.
● A process that waits too long in a lower-priority queue moved to a higher-priority queue.
● This form of aging prevents starvation.

Consider a multilevel feedback queue scheduler with three queues: queue0, queue1, queue2.
● The scheduler first executes all processes in queue0 then queue1 and then queue2.
● Only when queue and queue1 is empty, the scheduler will execute processes in queue2.
● A process that arrives for queue1 will preempt a process in queue2. A process in queue1
will in turn be preempted by a process arriving for queue0.
● A process entering the ready queue is put in queue0. A process in queue 0 is given a time
quantum of 8ms. If it does not finish within this time, it is moved to the tail of queue 1.
● If queue 0 is empty, the process at the head of queue1 is given a quantum of 16ms. If it
does not complete, it is preempted and is put into queue2.
● Processes in queue 2 are run on an FCFS basis but are run only when queues 0 and 1 are
empty.
● This scheduling algorithm gives highest priority to any process with a CPU burst of 8ms
or less. Such a process will quickly get the CPU and finish its CPU burst and go off to its
next I/O burst.
● Processes that need more than 8ms but less than 24ms are also served quickly, although
with lower priority than shorter processes.
● Long processes automatically sync to queue2 and are served in FCFS order with any
CPU cycles left over from queues0 and queue1.
A Multi-Level Feedback queue scheduler is defined by the following parameters:
● The number of queues.
● The scheduling algorithm for each queue.
● The method used to determine when to upgrade a process to a higher priority queue.
● The method used to determine when to demote a process to a lower priority queue.
● The method used to determine which queue a process will enter when that process needs
service.

THREAD SCHEDULING
Threads can be divided into two types: Kernel level threads and User level threads.
● Kernel-level threads are being scheduled by the operating system.
● User-level threads are managed by a Thread Library and the kernel is unaware of them.
● User-level threads must be mapped to an associated kernel-level thread to run on a CPU
Contention scope
● The thread library schedules user-level threads to run on an available Light Weight
Process. This scheme is known as Process-Contention Scope (PCS). There will be a
competition for the CPU among threads belonging to the same process.
● PCS is done according to priority. The scheduler selects the runnable thread with the
highest priority to run. User-level thread priorities are set by the programmer and are not
adjusted by the thread library.
● PCS will preempt the thread currently running in favor of a higher-priority thread.
● To decide which kernel-level thread to schedule onto a CPU, the kernel uses System-
 Contention Scope (SCS). Competition for the CPU with SCS scheduling takes place
among all threads in the system.
● Windows, Linux and Solaris are the systems scheduled threads using only SCS.

MULTIPLE-PROCESSOR SCHEDULING
Scheduling process will become complex with multiple CPU structures but Load Sharing is
possible with multiple CPU structures.
In multiple processor systems, we can use any available processor to run any process in
the queue.

Multiprocessor Scheduling Approaches

There are two approaches to multiprocessing: Asymmetric and Symmetric Multiprocessing.
● In Asymmetric Multiprocessing, Master and Worker relationships exist.
The master server is a single processor that handles the activities related to all scheduling
decisions, I/O processing and other system activities. The other processors execute only
user code.
● Asymmetric multiprocessing is simple because only one processor accesses the system
data structures, reducing the need for data sharing.
● In Symmetric Multiprocessing (SMP) each processor is self-scheduling. All processes
may be in a common ready queue or each processor may have its own private ready
queue processes.
● Scheduling proceeds by having the scheduler for each processor examine the ready
queue and select a process to execute.
● When multiple processors try to access and update a common data structure,
the scheduler must be programmed carefully.
● Two separate processors do not choose to schedule the same process and that
processes are not lost from the queue.
 Processor Affinity
The Process Affinity is “to make a process run on the same CPU it ran on last time”.
● The processor cache contains the data that is most recently accessed by the process.
● If the process migrates from one processor to another processor, the contents of cache
memory must be invalidated for the first processor and the cache for the second
processor must be entered again.
● Because of the high cost of invalidating and re-entering caches, most SMP systems try to
avoid migration of processes from one processor to another and instead attempt to keep a
process running on the same processor.
Processor affinity can be implemented in two ways: Soft affinity and Hard affinity.
● Soft affinity: The operating system will attempt to keep a process on a single
processor, but it is possible for a process to migrate between processors.
● Hard affinity: Some systems provide system calls that support Hard Affinity, thereby
allowing a process to specify a subset of processors on which it may run.

Load Balancing
Load balancing attempts to keep the workload evenly distributed across all processors in an
SMP system.
Load balancing is necessary only on systems where each processor has its own private queue
of processes to execute.
There are two approaches to load balancing: Push Migration and Pull Migration.
● Push migration: A specific process periodically checks the load on each processor. If
the task finds an imbalance then it evenly distributes the load by moving (pushing)
processes from overloaded processors to idle or less-busy processors.
● Pull migration: It occurs when an idle processor pulls a waiting process from a
busy processor.
 Multicore Processors
In a multicore processor each core acts as a separate processor. Multicore processors may
complicate scheduling issues.
● When a processor accesses memory, it spends a significant amount of time waiting for the data
to become available. This waiting time is called a Memory Stall.
● Memory Stall may occur for several reasons for example Cache miss.
● In order to avoid memory stall, many recent hardware designs have implemented multithreaded
processor cores in which two or more hardware threads are assigned to each core. That way, if
one thread stalls while waiting for memory, the core can switch to another thread.

● The execution of thread0 and the execution of thread 1 are interleaved on a dual-threaded
processor core.
● From an operating-system perspective, each Hardware Thread appears as a Logical
Processor that is available to run a software thread.
● Thus, on a Dual-threaded, Dual-core system, Four logical processors are presented to the
operating system.
There are two ways to multithread a processing core: Coarse-grained and Fine-grained
Coarse-Grained Multithreading:
● A thread executes on a processor until a long-latency event such as a memory stall occurs.

● The processor must switch to another thread to begin execution, because of the delay
caused by the long-latency event.
● The cost of switching between threads is high, since the instruction pipeline must be
flushed before the other thread can begin execution on the processor core.
● Once this new thread begins execution, it begins filling the pipeline with its instructions.

Fine-grained (or) Interleaved Multithreading:

● Thread switching done at the boundary of an instruction cycle.
● The architectural design of fine-grained systems includes logic for thread switching. As a
result, the cost of switching between threads is small.
 DEADLOCKS
A set of processes is in a Deadlock state when every process in the set is waiting for an event that
can be caused only by another process in the set. The events with which we are mainly
concerned here are resource acquisition and resource release.
SYSTEM MODEL
A system consists of a finite number of resources to be distributed among a number of
competing processes.
Resources are categorized into two types: Physical resources and Logical resources ∙
Physical resources: Printers, Tape drives, DVD drives, memory space and CPU cycles ∙
Logical resources: Semaphores, Mutex locks and files.
Each resource type consists of some number of identical instances. (i.e.) If a system has two
CPU’s then the resource type CPU has two instances.
A process may utilize a resource in the following sequence under normal mode of operation:
1. Request: The process requests the resource. If the resource is being used by another
process then the request cannot be granted immediately then the requesting process must wait
until it can acquire the resource.
2. Use: The process can operate on the resource.

Example: If the resource is a printer, the process can print on the

printer. 3. Release: The process releases the resource.
System calls for requesting and releasing resources:
∙ Device System calls: request( ) and release( )
∙ Semaphore System calls: wait( ), signal( )
∙ Mutex locks: acquire( ), release( ).
∙ Memory System Calls: allocate( ) and free( )
∙ File System calls: open( ), close( ).
A System Table maintains the status of each resource whether the resource is free or allocated.
For each resource that is allocated, the table also records the process to which it is allocated. If
a process requests a resource that is currently allocated to another process, it can be added to a
queue of processes waiting for this resource.
FOUR NECESSARY CONDITIONS OF DEADLOCK
A deadlock situation can arise if the following 4 conditions hold simultaneously in a system:
1. Mutual exclusion. Only one process at a time can use the resource. If other 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. If a process holding a resource and the resource cannot be
preempted until the 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.
 RESOURCE-ALLOCATION GRAPH
The resource allocation graph is used for identification of deadlocks in the system. A System
Resource-Allocation Graph G={V,E} is a directed graph that consists of a set of vertices V
and a set of edges E.
The set of vertices V is partitioned into two types of nodes: Processes and Resources.
1. Process set P= {P1, P2, ..., Pn} consisting of all the active processes in the system.
2. Resource set R= {R1, R2, ..., Rm} consisting of all resource types in the system.
The set of Edges E is divided into types: Request Edge and Assignment Edge. 1. Request
Edge (Pi → Rj): It signifies that process Pi has requested an instance of resource type Rj and
Pi is currently waiting for the resource Rj.
2. Assignment edge (Rj → Pi): It signifies that an instance of resource type Rj has been
allocated to process Pi.
Processes can be represented in Circles and Resources can be represented in Rectangles.
Instance of resource can be represented by a Dot.
Note:
1. When process Pi requests an instance of resource type Rj, a request edge is inserted in
the Resource-allocation graph.
2. When this request can be fulfilled, the request edge is transformed to an assignment edge.

3. When the process no longer needs access to the resource, it releases the resource and
the assignment edge is deleted.
Resource allocation graph shows three situations:
1. Graph with No deadlock
2. Graph with a cycle and deadlock
3. Graph with a cycle and no deadlock
Resource Allocation Graph without Deadlock
The below graph consists of three sets: Process P, Resources R and Edges E.

∙ Process set P= {P1, P2, P3}.

∙ Resources set R= {R1, R2, R3, R4}.
∙ Edge set E= E = {P1 → R1, P2 → R3, R1 → P2, R2 → P2, R2 → P1, R3 → P3}.
Resource type R1 and R3 has only one instance and R2 has two instances and R4 has three
instances.
The Resource Allocation Graph depicts that:
∙ R2 → P1, P1 → R1: P1 is holding an instance of resource type R2 and is waiting for
an instance of R1.
∙ R1 → P2, R2 → P2, P2 → R3: Process P2 is holding an instance of R1 and an instance
of R2 and is waiting for an instance of R3.
∙ R3 → P3: Process P3 is holding an instance of R3.
The above Resource allocation graph does not contain any cycle then there is no process in
the system is deadlocked.
Note:
1. If each resource type has exactly one instance then a cycle implies a deadlock. 2. If each
resource type has several instances then a cycle does not necessarily imply that a deadlock
has occurred.
Resource Allocation Graph with a Cycle and Deadlock

Consider the above graph, with processes and Resources and have some
edges: P1 → R1 → P2 → R3 → P3 → R2 → P1
P2 → R3 → P3 → R2 → P2
∙ Process P2 is waiting for the resource R3, which is held by process P3. ∙ Process
P3 is waiting for either process P1 or process P2 to release resource R2. ∙ Process
P1 is waiting for process P2 to release resource R1.
Hence the Processes P1, P2 and P3 are deadlocked.
Resource Allocation Graph with a Cycle and No Deadlock

The graph has a cycle: P1 → R1 → P3 → R2 → P1.

∙ This cycle does not lead to deadlock, because the process P4 and P2 is not waiting for
any resource.
 ∙ Process P4 may release its instance of resource type R2. That resource can then be allocated
to P3, breaking the cycle.

METHODS FOR HANDLING DEADLOCKS

The Deadlock can be handled by 3 methods:
1. Deadlock Prevention
2. Deadlock Avoidance
3. Deadlock Detection and Recovery
DEADLOCK PREVENTION
Deadlock prevention provides a set of methods to ensure that at least one of the necessary
conditions cannot hold. (i.e.) Deadlock can be prevented if any of Mutual Exclusion, Hold and
wait, No preemption and Circular wait condition cannot hold.
Mutual Exclusion
The mutual exclusion condition must hold when at least one resource must be non-sharable. ∙
We cannot prevent deadlocks by denying the mutual-exclusion condition, because some
resources by default are nonsharable.
Example 1: A mutex lock cannot be simultaneously shared by several

processes. Example 2: Printer is a resource where only one process can use it.
∙ Sharable resources do not require mutually exclusive access and thus cannot be involved in
a deadlock. Example: Read-only files.
∙ If several processes attempt to open a read-only file at the same time, they can be
granted simultaneous access to the file. A process never needs to wait for a sharable
resource.
Hold and Wait
To ensure that the hold-and-wait condition never occurs in the system, we must guarantee that,
whenever a process requests a resource, it does not hold any other resources. ∙ Protocol 1:
Each process can request the resources and be allocated all its resources
before it begins execution. We can implement this provision by requiring that system
calls requesting resources for a process precede all other system calls.
Example: Consider a process that copies data from a DVD drive to a file on Hard disk,
sorts the file and then prints the results to a Printer.
If all resources must be requested at the beginning of the process, then the process must
initially request the DVD drive, disk file and Printer. It will hold the printer for its entire
execution, even though it needs the printer only at the end.
∙ Protocol 2: A process can be allowed to request resources only when it has none. A process
may request some resources and use them. Before it can request any additional resources, it
must release all the resources that it is currently allocated.
Example: Consider a process that copies data from a DVD drive to a file on Hard disk,
sorts the file and then prints the results to a Printer.
The process to request initially only the DVD drive and Hard disk file. It copies from the
DVD drive to the Hard disk and then releases both the DVD drive and the disk file. The
process must then request the Hard disk file and the Printer. After copying the disk file
to the printer, it releases these two resources and terminates.
Problem: Starvation and Low Resource utilization
∙ Resource utilization is low, since resources may be allocated but unused for a long period.
∙ A process that needs several resources may have to wait indefinitely leads to starvation.
 No Preemption
To ensure that No preemption condition does not hold, we can use the following protocol: ∙ If
a process is holding some resources and requests another resource that cannot be immediately
allocated to it, then all resources the process is currently holding are preempted (i.e.)
resources are implicitly released.
∙ The preempted resources are added to the list of resources for which the process is waiting.
∙ The process will be restarted only when it can regain its old resources as well as the
new resources that it is requesting.
Note: This protocol is often applied to resources whose state can be easily saved and restored later
such as CPU registers and memory space. It cannot be applied to resources such as mutex
locks and semaphores.
Circular Wait
One way to ensure that circular wait 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.
Consider the set of resource types R={R1, R2, ..., Rm} and N be the set of natural

numbers. we define a one-to-one function F: R → N.

∙ The function assigns each resource type to a unique integer number, which allows us to
compare two resources and to determine whether one resource precedes another resource
in our ordering.
Example: If the set of resource types R includes tape drives, disk drives and printers, then the
function F: R → N might be defined as follows:
F (Tape drive) = 1 (F: Tape drive → 1) F
(Disk drive) = 5 (F: Disk drive → 1) F
(Printer) = 12 (F: Printer → 1)
We can now consider the following protocol to prevent deadlocks:
∙ Each process can request resources only in an increasing order of enumeration. That is, a
process can initially request any number of instances of a resource type Ri. ∙ After that, the
process can request instances of resource type Rj iff F(Rj) > F(Ri) ∙ Example: A process that
wants to use the tape drive and printer at the same time must first request the tape drive and
then request the printer.
∙ Alternatively, we can require that a process requesting an instance of resource type Rj
must have released any resources Ri such that F(Ri) ≥ F(Rj).
Note: If several instances of the same resource type are needed, a single request for all of
them must be issued.
Disadvantage of Deadlock Prevention
Deadlock-prevention algorithms leads to low resource utilization and the system throughput will
be reduced.
 DEADLOCK AVOIDANCE
In Deadlock avoidance the processes first informs the operating system about their maximum
allocation of resources to be requested and used during its life time.
∙ With this information, the operating system can decide for each request whether the
resource will be granted immediately or the process should wait for resources. ∙ To take this
decision about decision about the resource allocation, the operating system must consider
the resources currently available, the resources currently allocated to each process and the
future requests and releases of each process.
Algorithms for Deadlock Avoidance
A deadlock-avoidance algorithm dynamically examines the Resource-Allocation State to
ensure that a circular-wait condition can never exist.
The Resource Allocation State is defined by the number of available resources and allocated
resources and the maximum demands of the processes.
There are three algorithms are designed for deadlock avoidance:
1. Safe State
2. Resource Allocation Graph Algorithm
3. Bankers Algorithm
Safe State Algorithm

If the system can allocate resources to each process up to its maximum in some order and
still avoid a deadlock then the state is called Safe state.
∙ A system is in a safe state only if there exists a Safe sequence.
∙ A sequence of processes <P1, P2, ..., Pn> is a safe sequence for the current allocation state, if
for each process Pi, the resource requests that Pi can still make can be satisfied by the
currently available resources plus the resources held by all Pj, with j < i.
∙ In this situation, if the resources that Pi needs are not immediately available, then Pi can
wait until all Pj have finished.
∙ When Pj have finished its task, Pi can obtain all of its needed resources and after
completing its designated task Pi can return its allocated resources and terminate. ∙ When P i
terminates, Pi+1 can obtain its needed resources and so on.
∙ If no such sequence exists, then the system state is said to be unsafe.
Note:
1. A safe state is not a deadlocked state and a deadlocked state is an unsafe state. 2. An
unsafe state may lead to a deadlock but not all unsafe states are deadlocks. 3. As long as the
state is safe, the operating system can avoid unsafe and deadlocked states. 4. In an unsafe
state, operating system cannot prevent processes from requesting resources
in such a way that a deadlock occurs. Behavior of the processes controls unsafe

states.
Example: Consider a system with 12 magnetic tape drives and 3 processes: P0, P1 and P2.
Process Maximum Needs Current Needs
P0 10 5

P1 4 2

P2 9 2

The above table describes as follows:

∙ Process P0 requires 10 tape drives, P1 needs 4 tape drives and P2 need 9 tape drives. ∙
At time t0, process P0 is holding 5 tape drives, P1 and P2 is holding 2 tape drives each. ∙
Now there are 3 free tape drives.
At time t0, the system is in a safe state. <P1, P0, P2> sequence satisfies the safety condition.
∙ Process P1 can immediately be allocated all its tape drives and then return all 4 resources.
(i.e.) P1 currently holding 2 tape drives and out of 3 free tape drives 2 tape drives will be
given to P1. Now P1 is having all 4 resources. Hence P1 will use all of its resources and after
completing its task P1 releases all 4 resources and then returns to the system. Now the system
is having 5 available tape drives.

∙ Now process P0 needs 5 tape drives and the system has 5 available tape drives. Hence P0
can get all its tape drives and it reaches its maximum 10 tape drives. After completing its task
P0 returns the resources to the system. Now system has 10 available tape drives.
∙ Now the process P2 needs 7 additional resources and system have 10 resources available.
Hence process P2 can get all its tape drives and return them. Now the system will have all
12 tape drives available.
Problem: Low Resource utilization
If a process requests a resource that is currently available, it may still have to wait.
Hence there exist a low resource utilization is possible.
Resource-Allocation-Graph Algorithm
In this algorithm we use three edges: request edge, assignment edge and a claim edge. ∙ Claim
edge Pi → Rj indicates that process Pi may request resource Rj at some time in the future.
∙ Claim edge resembles a request edge in direction but is represented by dashed line. ∙ When
process Pi requests resource Rj, the claim edge Pi → Rj is converted to a request edge.
∙ When a resource Rj is released by Pi, the assignment edge Rj → Pi is reconverted to a
claim edge Pi → Rj.
∙ The resources must be claimed a priori in the system. That is, before process Pi starts
executing, all its claim edges must already appear in the resource-allocation graph.
Now suppose that process Pi requests resource Rj.
∙ The request can be granted only if converting the request edge Pi → Rj to an assignment
edge Rj → Pi does not result in the formation of a cycle in the resource-allocation graph.
We check for safety by using a cycle-detection algorithm.
∙ If no cycle exists, then the allocation of the resource will leave the system in a safe state. ∙
If a cycle is found, then the allocation will put the system in an unsafe state. In that case,
process Pi will have to wait for its requests to be satisfied.
Example: consider the above resource-allocation graph. Suppose that P2 requests R2. ∙ R2
is currently free still we cannot allocate it to P2, since this will create a cycle in graph. ∙ A
cycle indicates that the system is in an unsafe state.
∙ If P1 requests R2 and P2 requests R1, then a deadlock will occur.
Problem: The resource-allocation-graph algorithm is not applicable to a resource allocation
system with multiple instances of each resource type.
BANKER’s ALGORITHM
Banker’s algorithm is used in a system with multiple instance of each resource type. The name
was chosen because the algorithm could be used in a banking system to ensure that the bank
never allocated its available cash in such a way that it could no longer satisfy the needs of all
its customers.

Banker’s algorithm uses two algorithms:

1. Safety algorithm
2. Resource-Request algorithm
Process of Banker’s algorithm:
∙ When a new process enters the system, the process must declare the Maximum number of
instances of each resource type that it may need.
∙ The Maximum number may not exceed the Total number of resources in the system. ∙
When a user requests a set of resources, the system must determine whether the allocation
of these resources will leave the system in a safe state.
∙ If the system is in safe state then the resources are allocated.
∙ If the system is in unsafe state then the process must wait until some other process
releases enough resources.
Data structures used to implement the Banker’s algorithm
Consider the system with n number of processes and m number of resource types: ∙
Availablem: A vector of length m indicates the number of available resources of each type.
∙ Maxn × m: An n × m matrix defines the maximum demand of each process. ∙ Allocation n ×
m: An n × m matrix defines the number of resources of each type currently allocated to each
process.
∙ Need n × m: An n × m matrix indicates the remaining resource need of each process.
Need[i][j] = Max[i][j]−Allocation[i][j].
∙ Available[j] = k means then k instances of resource type Rj are available. ∙ Max[i][j]
= k means process Pi may request at most k instances of resource type Rj.

∙ Allocation[i][j]=k means process Pi is currently allocated k instances of resource type Rj. ∙

 Need[i][j]=k means process Pi may need k more instances of resource type Rj to complete
its task.
Each row in the matrices Allocation n × m and Need n × m are considered as vectors and refer to
them as Allocationi and Needi.
∙ The vector Allocationi specifies the resources currently allocated to process Pi. ∙ The vector
Needi specifies the additional resources that process Pi may still request to complete its task.
Safety algorithm
Safety algorithm finds out whether the system is in safe state or not. The algorithm can be
described as follows:
1. Let Work and Finish be vectors of length m and n, respectively. We initialize
Work = Available
Finish[i] = false for i = 0, 1, ..., n − 1.
2. Find an index i such that both
Finish[i] == false
Needi ≤ Work
If no such i exists, go to step 4.
3. Work = Work +
Allocationi Finish[i] =
true
Go to step 2.
4. If Finish[i] == true for all i, then the system is in a safe state.

Note: To determine a safe state, this algorithm requires an order of m×n2operations.

Resource-Request Algorithm
This algorithm determines whether requests can be safely granted.
Let Requesti be the request vector for process Pi. If Requesti [ j] == k, then process Pi wants
k instances of resource type Rj.
When a request for resources is made by process Pi, the following actions are
taken: 1. If Requesti ≤ Needi, go to step 2.
Otherwise, raise an error condition, since the process has exceeded its maximum
claim. 2. If Requesti ≤ Available, go to step 3.
Otherwise, Pi must wait, since the resources are not available.
3. Have the system pretend to have allocated the requested resources to process Pi
by modifying the state as follows:
Available = Available– Requesti ;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti ;
4. If the resulting resource-allocation state is safe, the transaction is completed and process
Pi is allocated its resources.
If the new state is unsafe, then Pi must wait for Requesti and the old resource-allocation
state is restored.

Example for Banker’s Algorithm

Consider a system with 5 processes: P0, P1, P2, P3, P4 and 3 resource types A, B and C with
10, 5, 7 instances respectively. (i.e.) . Resource type A=10, B= 5 and C=7 instances. Suppose
that, at time T0, the following snapshot of the system has been taken:
Allocation Max Available
 Process A B C A B C A B C
P0 01 753 332
0
P1 20 322
0
P2 30 902
2
P3 21 222
1
P4 00 433
2

The Available vector can be calculated by subtractring total no of resources from the sum of resources
allocated to each process.
Available resources of A= Total resources of A – Sum of resources allocated to Process P1 to P4

The Need matrix can be obtained by using Need[i][j] = Max[i][j]−Allocation[i][j]

Max Allocation Need
ABCABCABC
P0 7 5 3 0 1 0 7 4 3
P1 3 2 2 2 0 0 1 2 2
P2 9 0 2 3 0 2 6 0 0
P3 2 2 2 2 1 1 0 1 1
P4 4 3 3 0 0 2 4 3 1

By using the banker’s algorithm

we can decide whether the state is safe or not. After solving the above problem by using bankers
algorithm we will get to a safe state with safe sequence
<P1,P3,P4,P0,P2>.
Now we get a safe state, the resources will be granted immediately for requested process P1.
DEADLOCK DETECTION ALGORITHM
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.
Deadlock Detection in Single Instance of Each Resource Type
If all resources have only a single instance then we can define a Deadlock-Detection
algorithm that uses a variant of the resource-allocation graph called a wait-for graph. We
obtain wait-for graph from the resource-allocation graph by removing the resource nodes and
collapsing the appropriate edges.
∙ An edge from Pi to Pj in a wait-for graph implies that process Pi is waiting for process Pj
to release a resource that Pi needs.
∙ An edge Pi → Pj exists in a wait-for graph if and only if the corresponding resource
allocation graph contains two edges Pi → Rq and Rq → Pj for some resource Rq .
 ∙ In above figure we present a resource-allocation graph and the corresponding wait-for
graph. A deadlock exists in the system if and only if the wait-for graph contains a cycle. ∙
To detect deadlocks, the system needs to maintain the wait-for graph and periodically
invoke an algorithm that searches for a cycle in the graph.
∙ An algorithm to detect a cycle in a graph requires an order of n2operations, where n is
the number of vertices in the graph.
Several Instances of a Resource Type
The wait-for graph scheme is not applicable to a resource-allocation system with multiple
instances of each resource type.
We will implement a Deadlock Detection algorithm that is similar to the Banker’s
algorithm. The data structures used in Deadlock Detection algorithm is:
∙ Available: A vector of length m indicates the number of available resources of each type. ∙

Allocation: An n × m matrix defines the number of resources of each type currently allocated
to each process.
∙ Request: An n × m matrix indicates the current request of each process. If
Request[i][j]==k, then process Pi is requesting k more instances of resource type Rj.
The detection algorithm described here simply investigates every possible allocation
sequence for the processes that remain to be completed.
1. Let Work and Finish be vectors of length m and n, respectively. We Initialize
Work = Available. For i = 0, 1, ..., n–1.
if Allocationi != 0, then Finish[i] = false.
Otherwise, Finish[i] = true.
2. Find an index i such that both
a. Finish[i] == false
b. Requesti ≤ Work
If no such i exists, go to step 4.
3. Work = Work + Allocationi
Finish[i] = true
Go to step 2.
4. If Finish[i] == false for some i, 0 ≤ i < n, then the system is in a deadlocked state.
Moreover, if Finish[i] == false, then process Pi is deadlocked.
5. This algorithm requires an order of m × n2operations to detect whether the system is in a
deadlocked state.
6. Example:
7. Consider a system with 5 processes: P0, P1, P2, P3, P4 and 3 resource types A, B and C
with 10, 5, 7 instances respectively. (i.e.) . Resource type A=7, B= 2 and C=6 instances.
Suppose that, at time T0, we have the following resource-allocation state:
 Allocation Request Available
ABC ABC ABC
P 010 000 000
0
P 200 202
1
P 303 000
2
P 211 100
3
P 002 002
4

Initially the system is not in Deadlock State. If we apply the Deadlock Detection algorithm we will find the
sequence < P0, P2, P3, P1, P4 > results in Finish[i] == true for all i. The system is in safe state hence there is
no deadlock
 RECOVERY FROM DEADLOCK
There are two options for breaking a deadlock.
1. Process termination

2. Resource Preemption

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 method
incurs considerable overhead, since after each process is aborted, a deadlock-
detection algorithm must be invoked to determine whether any processes are still
deadlocked.
Many factors may affect which process is chosen for
preempting includes: 1. Priority of the process.
2. How long the process has computed and how much longer the process will compute
before completing its designated task.
3. How many and what types of resources the process has used.

4. How many more resources the process needs in order to complete.

5. How many processes will need to be terminated?

6. Whether the process is Interactive or Batch.

Resource Preemption
To eliminate deadlocks using resource preemption, we successively preempt some
resources from processes and give these resources to other processes until the deadlock
cycle is broken. There are 3 issues related to Resource Preemption:
1. Selecting a victim. As in process termination, we must determine the order of
preemption to minimize cost. Cost factors may include the number of resources a
deadlocked process is holding and the amount of time the process has thus far
consumed.
2. Rollback. If we preempt a resource from a process then the process cannot continue
with its normal execution. It is missing some needed resource. We must do total roll
back of the process and restart it from that state: abort the process and then restart it.
3. Starvation. How do we ensure that starvation will not occur? That is, how can we
guarantee that resources will not always be preempted from the same process? In
a system where victim selection is based on cost factors, it may happen that the
same process is always picked as a victim. As a result, this process never
completes its task which leads to starvation. Hence we must ensure that a process
can be picked as a victim only a finite number of times. The solution is to include
the number of rollbacks in the cost factor.