Unit 3

CPU Scheduling: Basic Concepts

Scheduling of processes/work is done to finish the work on time. CPU Scheduling is a process that allows one process to use the CPU while another process is
delayed (in standby) due to unavailability of any resources such as I / O etc, thus making full use of the CPU. The purpose of CPU Scheduling is to make the
system more efficient, faster, and fairer. Whenever the CPU becomes idle, the operating system must select one of the processes in the line ready for launch. The
selection process is done by a temporary (CPU) scheduler. The Scheduler selects between memory processes ready to launch and assigns the CPU to one of
them. Process Scheduling is an integral part of Multi-programming applications. Such operating systems allow more than one process to be loaded into usable
memory at a time and the loaded shared CPU process uses repetition time.
There are three types of process schedulers:
• Long term or Job Scheduler
• Short term or CPU Scheduler
• Medium-term Scheduler
Why do we need to schedule processes?
• Scheduling is important in many different computer environments. One of the most important areas is scheduling which programs will work on the CPU. This
task is handled by the Operating System (OS) of the computer and there are many different ways in which we can choose to conf igure programs.
• Process Scheduling allows the OS to allocate CPU time for each process. Another important reason to use a process scheduling system is that it keeps the
CPU busy at all times. This allows you to get less response time for programs.
• Considering that there may be hundreds of programs that need to work, the OS must launch the program, stop it, switch to another program, etc. The way the
OS configures the system to run another in the CPU is called “context switching”. If the OS keeps context-switching programs in and out of the provided CPUs,
it can give the user a tricky idea that he or she can run any programs he or she wants to run, all at once.
• So now that we know we can run 1 program at a given CPU, and we know we can change the operating system and remove another one using the context
switch, how do we choose which programs we need. run, and with what program?
• That’s where scheduling comes in! First, you determine the metrics, saying something like “the amount of time until the end”. We will define this metric as “the
time interval between which a function enters the system until it is completed”. Second, you decide on a metrics that reduces metrics. We want our tasks to end
as soon as possible.
What is the need for CPU scheduling algorithm?
CPU scheduling is the process of deciding which process will own the CPU to use while another process is suspended. The main function of the CPU scheduling
is to ensure that whenever the CPU remains idle, the OS has at least selected one of the processes available in the ready-to-use line.
In Multiprogramming, if the long-term scheduler selects multiple I / O binding processes then most of the time, the CPU remains an idle. The function of an
effective program is to improve resource utilization.
If most operating systems change their status from performance to waiting then there may always be a chance of failure in the system. So in order to minimize this
excess, the OS needs to schedule tasks in order to make full use of the CPU and avoid the possibility of deadlock.
Objectives of Process Scheduling Algorithm:
• Utilization of CPU at maximum level. Keep CPU as busy as possible.
• Allocation of CPU should be fair.
• Throughput should be Maximum. i.e. Number of processes that complete their execution per time unit should be maximized.
• Minimum turnaround time, i.e. time taken by a process to finish execution should be the least.
• There should be a minimum waiting time and the process should not starve in the ready queue.
• Minimum response time. It means that the time when a process produces the first response should be as less as possible.
What are the different terminologies to take care of in any CPU Scheduling algorithm?
• Arrival Time: Time at which the process arrives in the ready queue.
• Completion Time: Time at which process completes its execution.
• Burst Time: Time required by a process for CPU execution.
• Turn Around Time: Time Difference between completion time and arrival time.
Turn Around Time = Completion Time – Arrival Time
• Waiting Time(W.T): Time Difference between turn around time and burst time.
 Waiting Time = Turn Around Time – Burst Time

Things to take care while designing a CPU Scheduling algorithm?

Different CPU Scheduling algorithms have different structures and the choice of a particular algorithm depends on a variety of factors. Many conditions have
been raised to compare CPU scheduling algorithms.
The criteria include the following:
• CPU utilization: The main purpose of any CPU algorithm is to keep the CPU as busy as possible. Theoretically, CPU usage can range from 0 to 100 but in a
real-time system, it varies from 40 to 90 percent depending on the system load.
• Throughput: The average CPU performance is the number of processes performed and completed during each unit. This is called throughput. The output may
vary depending on the length or duration of the processes.
• Turn round Time: For a particular process, the important conditions are how long it takes to perform that process. The time elapsed from the t ime of process
delivery to the time of completion is known as the conversion time. Conversion time is the amount of time spent waiting for memory access, waiting in line,
using CPU, and waiting for I / O.
• Waiting Time: The Scheduling algorithm does not affect the time required to complete the process once it has started performing. It only affects the waiting
time of the process i.e. the time spent in the waiting process in the ready queue.
• Response Time: In a collaborative system, turn around time is not the best option. The process may produce something early and continue to computing the
new results while the previous results are released to the user. Therefore another method is the time taken in the submission of the application process until
the first response is issued. This measure is called response time.
What are the different types of CPU Scheduling Algorithms?
There are mainly two types of scheduling methods:
• Preemptive Scheduling: Preemptive scheduling is used when a process switches from running state to ready state or from the waiting state to the re ady state.
• Non-Preemptive Scheduling: Non-Preemptive scheduling is used when a process terminates , or when a process switches from running state to waiting state.
 Different types of CPU Scheduling Algorithms

Let us now learn about these CPU scheduling algorithms in operating systems one by one:
1. First Come First Serve:
FCFS considered to be the simplest of all operating system scheduling algorithms. First come first serve scheduling algorithm stat es that the process that
requests the CPU first is allocated the CPU first and is implemented by using FIFO queue.
Characteristics of FCFS:
• FCFS supports non-preemptive and preemptive CPU scheduling algorithms.
• Tasks are always executed on a First-come, First-serve concept.
• FCFS is easy to implement and use.
• This algorithm is not much efficient in performance, and the wait time is quite high.
Advantages of FCFS:
• Easy to implement
• First come, first serve method
Disadvantages of FCFS:
• FCFS suffers from Convoy effect.
• The average waiting time is much higher than the other algorithms.
• FCFS is very simple and easy to implement and hence not much efficient.
To learn about how to implement this CPU scheduling algorithm, please refer to our detailed article on First come, First serve Scheduling.
2. Shortest Job First(SJF):
Shortest job first (SJF) is a scheduling process that selects the waiting process with the smallest execution time to execute next. This scheduling method may or
may not be preemptive. Significantly reduces the average waiting time for other processes waiting to be executed. The full form of SJF is Shortest Job First.
 Characteristics of SJF:
• Shortest Job first has the advantage of having a minimum average waiting time among all operating system scheduling algorithms.
• It is associated with each task as a unit of time to complete.
• It may cause starvation if shorter processes keep coming. This problem can be solved using the concept of ageing.
Advantages of Shortest Job first:
• As SJF reduces the average waiting time thus, it is better than the first come first serve scheduling algorithm.
• SJF is generally used for long term scheduling
Disadvantages of SJF:
• One of the demerit SJF has is starvation.
• Many times it becomes complicated to predict the length of the upcoming CPU request
To learn about how to implement this CPU scheduling algorithm, please refer to our detailed art icle on Shortest Job First.
3. Longest Job First(LJF):
Longest Job First(LJF) scheduling process is just opposite of shortest job first (SJF), as the name suggests this algorithm is based upon the fact that the
process with the largest burst time is processed first. Longest Job First is non-preemptive in nature.
Characteristics of LJF:
• Among all the processes waiting in a waiting queue, CPU is always assigned to the process having largest burst time.
• If two processes have the same burst time then the tie is broken using FCFS i.e. the process that arrived first is processed first.
• LJF CPU Scheduling can be of both preemptive and non-preemptive types.
Advantages of LJF:
• No other task can schedule until the longest job or process executes completely.
• All the jobs or processes finish at the same time approximately.
Disadvantages of LJF:
• Generally, the LJF algorithm gives a very high average waiting time and average turn-around time for a given set of processes.
• This may lead to convoy effect.
To learn about how to implement this CPU scheduling algorithm, please refer to our detailed article on the Longest job first scheduling.
4. Priority Scheduling:
Preemptive Priority CPU Scheduling Algorithm is a pre-emptive method of CPU scheduling algorithm that works based on the priority of a process. In this
algorithm, the editor sets the functions to be as important, meaning that the most important process must be done first. In the case of any conflict, that is, where
there are more than one processor with equal value, then the most important CPU planning algorithm works on the basis of the FCFS (First Come First Serve)
algorithm.
Characteristics of Priority Scheduling:
• Schedules tasks based on priority.
• When the higher priority work arrives while a task with less priority is executed, the higher priority work takes the place of the less priority one and
• The latter is suspended until the execution is complete.
• Lower is the number assigned, higher is the priority level of a process.
Advantages of Priority Scheduling:
• The average waiting time is less than FCFS
• Less complex
Disadvantages of Priority Scheduling:
• One of the most common demerits of the Preemptive priority CPU scheduling algorithm is the Starvation Problem. This is the problem in which a process has
to wait for a longer amount of time to get scheduled into the CPU. This condition is called the starvation problem.
To learn about how to implement this CPU scheduling algorithm, please refer to our detailed article on Priority Preemptive Scheduling algorithm.
5. Round robin:
Round Robin is a CPU scheduling algorithm where each process is cyclically assigned a fixed time slot. It is the preemptive version of First come First Serve
CPU Scheduling algorithm. Round Robin CPU Algorithm generally focuses on Time Sharing technique.
Characteristics of Round robin:
• It’s simple, easy to use, and starvation-free as all processes get the balanced CPU allocation.
• One of the most widely used methods in CPU scheduling as a core.
• It is considered preemptive as the processes are given to the CPU for a very limited time.
Advantages of Round robin:
• Round robin seems to be fair as every process gets an equal share of CPU.
• The newly created process is added to the end of the ready queue.
To learn about how to implement this CPU scheduling algorithm, please refer to our detailed article on the Round robin Scheduling algorithm.

6. Shortest Remaining Time First:

Shortest remaining time first is the preemptive version of the Shortest job first which we have discussed earlier where the processor is allocated to the j ob
closest to completion. In SRTF the process with the smallest amount of time remaining until completion is selected to execute.
Characteristics of Shortest remaining time first:
• SRTF algorithm makes the processing of the jobs faster than SJF algorithm, given it’s overhead charges are not counted.
• The context switch is done a lot more times in SRTF than in SJF and consumes the CPU’s valuable time for processing. This adds up to its processing time
and diminishes its advantage of fast processing.
Advantages of SRTF:
• In SRTF the short processes are handled very fast.
• The system also requires very little overhead since it only makes a decision when a process completes or a new process is added.
Disadvantages of SRTF:
• Like the shortest job first, it also has the potential for process starvation.
• Long processes may be held off indefinitely if short processes are continually added.
To learn about how to implement this CPU scheduling algorithm, please refer to our detailed article on the shortest remaining time first.

Scheduling Criteria
Many criteria have been suggested for comparing CPU scheduling algorithms.
The criteria include the following:
1. CPU utilization: The main objective of any CPU scheduling algorithm is to keep the CPU as busy as possible. Theoretically, CPU utilization can range from 0
to 100 but in a real-time system, it varies from 40 to 90 percent depending on the load upon the system.
2. Throughput: A measure of the work done by the CPU is the number of processes being executed and completed per unit of time. This is called throughput.
The throughput may vary depending on the length or duration of the processes.
3. Turnaround time: For a particular process, an important criterion is how long it takes to execute that process. The time elapsed from the time of submission of
a process to the time of completion is known as the turnaround time. Turn-around time is the sum of times spent waiting to get into memory, waiting in the
ready queue, executing in CPU, and waiting for I/O. The formula to calculate Turn Around Time = Compilation Time – Arrival Time.
4. Waiting time: A scheduling algorithm does not affect the time required to complete the process once it starts execution. It only affects the waiting time of a
process i.e. time spent by a process waiting in the ready queue. The formula for calculating Waiting Time = Turnaround Time – Burst Time.
5. Response time: In an interactive system, turn-around time is not the best criterion. A process may produce some output fairly early and continue computing
new results while previous results are being output to the user. Thus another criterion is the time taken from submission of the process of the request until the
first response is produced. This measure is called response time. The formula to calculate Response Time = CPU Allocation Time(when the CPU was
allocated for the first) – Arrival Time
6. Completion time: The completion time is the time when the process stops executing, which means that the process has completed its burst time and is
completely executed.
7. Priority: If the operating system assigns priorities to processes, the scheduling mechanism should favor the higher-priority processes.
8. Predictability: A given process always should run in about the same amount of time under a similar system load.

Scheduling Algorithms
• First-Come, First-Served (FCFS) Scheduling
• Shortest-Job-Next (SJN) Scheduling
 • Priority Scheduling
• Shortest Remaining Time
• Round Robin(RR) Scheduling
• Multiple-Level Queues Scheduling
These algorithms are either non-preemptive or preemptive. Non-preemptive algorithms are designed so that once a process enters the running state, it cannot be preempted
until it completes its allotted time, whereas the preemptive scheduling is based on priority where a scheduler may preempt a low priority running process anytime when a high
priority process enters into a ready state.

First Come First Serve (FCFS)

• Jobs are executed on first come, first serve basis.

• It is a non-preemptive, pre-emptive scheduling algorithm.
• Easy to understand and implement.
• Its implementation is based on FIFO queue.
• Poor in performance as average wait time is high.

Wait time of each process is as follows −

Process Wait Time : Service Time - Arrival Time

P0 0-0=0

P1 5-1=4

P2 8-2=6

P3 16 - 3 = 13

Average Wait Time: (0+4+6+13) / 4 = 5.75

Shortest Job Next (SJN)

• This is also known as shortest job first, or SJF

• This is a non-preemptive, pre-emptive scheduling algorithm.
• Best approach to minimize waiting time.
• Easy to implement in Batch systems where required CPU time is known in advance.
• Impossible to implement in interactive systems where required CPU time is not known.
• The processer should know in advance how much time process will take.
Given: Table of processes, and their Arrival time, Execution time

Process Arrival Time Execution Time Service Time

P0 0 5 0

P1 1 3 5

P2 2 8 14

P3 3 6 8

Waiting time of each process is as follows −

Process Waiting Time

P0 0-0=0

P1 5-1=4

P2 14 - 2 = 12

P3 8-3=5
Average Wait Time: (0 + 4 + 12 + 5)/4 = 21 / 4 = 5.25

Priority Based Scheduling

• Priority scheduling is a non-preemptive algorithm and one of the most common scheduling algorithms in batch systems.
• Each process is assigned a priority. Process with highest priority is to be executed first and so on.
• Processes with same priority are executed on first come first served basis.
• Priority can be decided based on memory requirements, time requirements or any other resource requirement.
Given: Table of processes, and their Arrival time, Execution time, and priority. Here we are considering 1 is the lowest priority.

Process Arrival Time Execution Time Priority Service Time

P0 0 5 1 0

P1 1 3 2 11

P2 2 8 1 14

P3 3 6 3 5

Waiting time of each process is as follows −

Process Waiting Time

P0 0-0=0

P1 11 - 1 = 10

P2 14 - 2 = 12

P3 5-3=2
Average Wait Time: (0 + 10 + 12 + 2)/4 = 24 / 4 = 6

Shortest Remaining Time

• Shortest remaining time (SRT) is the preemptive version of the SJN algorithm.
• The processor is allocated to the job closest to completion but it can be preempted by a newer ready job with shorter time to completion.
• Impossible to implement in interactive systems where required CPU time is not known.
• It is often used in batch environments where short jobs need to give preference.

Round Robin Scheduling

• Round Robin is the preemptive process scheduling algorithm.

• Each process is provided a fix time to execute, it is called a quantum.
• Once a process is executed for a given time period, it is preempted and other process executes for a given time period.
• Context switching is used to save states of preempted processes.

Wait time of each process is as follows −

Process Wait Time : Service Time - Arrival Time

P0 (0 - 0) + (12 - 3) = 9

P1 (3 - 1) = 2

P2 (6 - 2) + (14 - 9) + (20 - 17) = 12

P3 (9 - 3) + (17 - 12) = 11

Average Wait Time: (9+2+12+11) / 4 = 8.5

Multiple-Level Queues Scheduling

Multiple-level queues are not an independent scheduling algorithm. They make use of other existing algorithms to group and schedule jobs with common characteristics.

• Multiple queues are maintained for processes with common characteristics.

• Each queue can have its own scheduling algorithms.
• Priorities are assigned to each queue.
 For example, CPU-bound jobs can be scheduled in one queue and all I/O-bound jobs in another queue. The Process Scheduler then alternately selects jobs from each queue
and assigns them to the CPU based on the algorithm assigned to the queue.

Thread Scheduling
Scheduling of threads involves two boundary scheduling,

• Scheduling of user level threads (ULT) to kernel level threads (KLT) via lightweight process (LWP) by the application develop er.
• Scheduling of kernel level threads by the system scheduler to perform different unique os functions.
Lightweight Process (LWP) :
Light-weight process are threads in the user space that acts as an interface for the ULT to access the physical CPU resources. Thread library schedules which
thread of a process to run on which LWP and how long. The number of LWP created by the thread library depends on the type of application. In the case of an I/O
bound application, the number of LWP depends on the number of user-level threads. This is because when an LWP is blocked on an I/O operation, then to invoke
the other ULT the thread library needs to create and schedule another LWP. Thus, in an I/O bound application, the number of LWP is equal to the number of the
ULT. In the case of a CPU bound application, it depends only on the application. Each LWP is attached to a separate kernel-level thread.
 In real-time, the first boundary of thread scheduling is beyond specifying the scheduling policy and the priority. It requires two co ntrols to be specified for the User
level threads: Contention scope, and Allocation domain. These are explained as following below.
1. Contention Scope :
The word contention here refers to the competition or fight among the User level threads to access the kernel resources. Thus, this control defines the extent to
which contention takes place. It is defined by the application developer using the thread library. Depending upon the extent of contention it is classified
as Process Contention Scope and System Contention Scope.

1. Process Contention Scope (PCS) –

The contention takes place among threads within a same process. The thread library schedules the high-prioritized PCS thread to access the resources via
available LWPs (priority as specified by the application developer during thread creation).

2. System Contention Scope (SCS) –

The contention takes place among all threads in the system. In this case, every SCS thread is associated to each LWP by the thread library and are
scheduled by the system scheduler to access the kernel resources.
In LINUX and UNIX operating systems, the POSIX Pthread library provides a function Pthread_attr_setscope to define the type of contention scope for a thread
during its creation.

int Pthread_attr_setscope(pthread_attr_t *attr, int scope)

1. The first parameter denotes to which thread within the process the scope is defined.
The second parameter defines the scope of contention for the thread pointed. It takes two values.

PTHREAD_SCOPE_SYSTEM
PTHREAD_SCOPE_PROCESS
1. If the scope value specified is not supported by the system, then the function returns ENOTSUP.

2. Allocation Domain :
The allocation domain is a set of one or more resources for which a thread is competing. In a multicore system, there may be one or more allocation domains
where each consists of one or more cores. One ULT can be a part of one or more allocation domain. Due to this high complexity in dealing with hardware and
software architectural interfaces, this control is not specified. But by default, the multicore system will have an interface that affects the allocation domain of a
thread.
Consider a scenario, an operating system with three process P1, P2, P3 and 10 user level threads (T1 to T10) with a single allocation domain. 100% of CPU
resources will be distributed among all the three processes. The amount of CPU resources allocated to each process and to each thread depends on the
contention scope, scheduling policy and priority of each thread defined by the application developer using thread library and also depends on the system
scheduler. These User level threads are of a different contention scope.
 In this case, the contention for allocation domain takes place as follows,

1. Process P1:
All PCS threads T1, T2, T3 of Process P1 will compete among themselves. The PCS threads of the same process can share one or more LWP. T1 and T2
share an LWP and T3 are allocated to a separate LWP. Between T1 and T2 allocation of kernel resources via LWP is based on preemptive priority scheduling
by the thread library. A Thread with a high priority will preempt low priority threads. Whereas, thread T1 of process p1 cann ot preempt thread T3 of process p3
even if the priority of T1 is greater than the priority of T3. If the priority is equal, then the allocation of ULT to available LWPs is based on the scheduling policy
of threads by the system scheduler(not by thread library, in this case).

2. Process P2:
Both SCS threads T4 and T5 of process P2 will compete with processes P1 as a whole and with SCS threads T8, T9, T10 of process P3. The system
scheduler will schedule the kernel resources among P1, T4, T5, T8, T9, T10, and PCS threads (T6, T7) of process P3 considerin g each as a separate process.
Here, the Thread library has no control of scheduling the ULT to the kernel resources.

3. Process P3:
Combination of PCS and SCS threads. Consider if the system scheduler allocates 50% of CPU resources to process P3, then 25% of resources is for process
scoped threads and the remaining 25% for system scoped threads. The PCS threads T6 and T7 will be allocated to access the 25% resources based on the
priority by the thread library. The SCS threads T8, T9, T10 will divide the 25% resources among themselves and access the kernel resources via separate
LWP and KLT. The SCS scheduling is by the system scheduler.

Note:
For every system call to access the kernel resources, a Kernel Level thread is created and associated to separate LWP by the system scheduler.
 Number of Kernel Level Threads = Total Number of LWP
Total Number of LWP = Number of LWP for SCS + Number of LWP for PCS
Number of LWP for SCS = Number of SCS threads
Number of LWP for PCS = Depends on application developer
Here,

Number of SCS threads = 5

Number of LWP for PCS = 3
Number of SCS threads = 5
Number of LWP for SCS = 5
Total Number of LWP = 8 (=5+3)
Number of Kernel Level Threads = 8
Advantages of PCS over SCS :

• If all threads are PCS, then context switching, synchronization, scheduling everything takes place within the userspace. This reduces system calls and
achieves better performance.

• PCS is cheaper than SCS.

• PCS threads share one or more available LWPs. For every SCS thread, a separate LWP is associated.For every system call, a separate KLT is created.

• The number of KLT and LWPs created highly depends on the number of SCS threads created. This increases the kernel complexity of handling scheduling and
synchronization. Thereby, results in a limitation over SCS thread creation, stating that, the number of SCS threads to be smaller than the number of PCS
threads.

Multiple-Processor Scheduling

Approaches to Multiple Processor Scheduling

There are two approaches to multiple processor scheduling in the operating system: Symmetric Multiprocessing and Asymmetric Multiprocessing.
 1. Symmetric Multiprocessing: It is used where each processor is self-scheduling. All processes may be in a common ready queue, or each processor may have its private
queue for ready processes. The scheduling proceeds further by having the scheduler for each processor examine the ready queue and select a process to execute.
2. Asymmetric Multiprocessing: It is used when all the scheduling decisions and I/O processing are handled by a single processor called the Master Server. The other
processors execute only the user code. This is simple and reduces the need for data sharing, and this entire scenario is called Asymmetric Multiprocessing.

Processor Affinity

Processor Affinity means a process has an affinity for the processor on which it is currently running. When a process runs on a specific processor, there are certain effects on the
cache memory. The data most recently accessed by the process populate the cache for the processor. As a result, successive memory access by the process is often satisfied in
the cache memory.

Now, suppose the process migrates to another processor. In that case, the contents of the cache memory must be invalidated for the first processor, and the cache for the second
processor must be repopulated. Because of the high cost of invalidating and repopulating caches, most SMP(symmetric multiprocessing) systems try to avoid migrating processes
from one processor to another and keep a process running on the same processor. This is known as processor affinity. There are two types of processor affinity, such as:

1. Soft Affinity: When an operating system has a policy of keeping a process running on the same processor but not guaranteeing it will do so, this situation is called soft
affinity.
2. Hard Affinity: Hard Affinity allows a process to specify a subset of processors on which it may run. Some Linux systems implement soft affinity and provide system calls
like sched_setaffinity() that also support hard affinity.

Load Balancing

Load Balancing is the phenomenon that keeps 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 a process that is eligible to execute.

Load balancing is unnecessary because it immediately extracts a runnable process from the common run queue once a processor becomes idle. On SMP (symmetric
multiprocessing), it is important to keep the workload balanced among all processors to utilize the benefits of having more than one processor fully. One or more processors will
sit idle while other processors have high workloads along with lists of processors awaiting the CPU. There are two general approaches to load balancing:
 1. Push Migration: In push migration, a task routinely checks the load on each processor. If it finds an imbalance, it evenly distributes the load on each processor by
moving the processes from overloaded to idle or less busy processors.
2. Pull Migration:Pull Migration occurs when an idle processor pulls a waiting task from a busy processor for its execution.

Multi-core Processors

In multi-core processors, multiple processor cores are placed on the same physical chip. Each core has a register set to maintain its architectural state and thus appears to the
operating system as a separate physical processor. SMP systems that use multi-core processors are faster and consume less power than systems in which each processor has its
own physical chip.

However, multi-core processors may complicate the scheduling problems. When the processor accesses memory, it spends a significant amount of time waiting for the data to
become available. This situation is called a Memory stall. It occurs for various reasons, such as cache miss, which is accessing the data that is not in the cache memory.

In such cases, the processor can spend upto 50% of its time waiting for data to become available from memory. To solve this problem, recent hardware designs have implemented
multithreaded processor cores in which two or more hardware threads are assigned to each core. Therefore if one thread stalls while waiting for the memory, the core can switch
to another thread. There are two ways to multithread a processor:

1. Coarse-Grained Multithreading: A thread executes on a processor until a long latency event such as a memory stall occurs in coarse-grained multithreading. Because
of the delay caused by the long latency event, the processor must switch to another thread to begin execution. The cost of switching between threads is high as the
instruction pipeline must be terminated 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.
2. Fine-Grained Multithreading: This multithreading switches between threads at a much finer level, mainly at the boundary of an instruction cycle. The architectural
design of fine-grained systems includes logic for thread switching, and as a result, the cost of switching between threads is small.
Symmetric Multiprocessor

Symmetric Multiprocessors (SMP) is the third model. There is one copy of the OS in memory in this model, but any central processing unit can run it. Now, when a system call is
made, the central processing unit on which the system call was made traps the kernel and processed that system call. This model balances processes and memory dynamically.
This approach uses Symmetric Multiprocessing, where each processor is self-scheduling.

The scheduling proceeds further by having the scheduler for each processor examine the ready queue and select a process to execute. In this system, this is possible that all the
process may be in a common ready queue or each processor may have its private queue for the ready process. There are mainly three sources of contention that can be found in
a multiprocessor operating system.

o Locking system: As we know that the resources are shared in the multiprocessor system, there is a need to protect these resources for safe access among the multiple
processors. The main purpose of the locking scheme is to serialize access of the resources by the multiple processors.
o Shared data: When the multiple processors access the same data at the same time, then there may be a chance of inconsistency of data, so to protect this, we have to
use some protocols or locking schemes.
o Cache coherence: It is the shared resource data that is stored in multiple local caches. Suppose two clients have a cached copy of memory and one client change the
memory block. The other client could be left with an invalid cache without notification of the change, so this conflict can be resolved by maintaining a coherent view of
the data.

Master-Slave Multiprocessor

In this multiprocessor model, there is a single data structure that keeps track of the ready processes. In this model, one central processing unit works as a master and another as
a slave. All the processors are handled by a single processor, which is called the master server.

The master server runs the operating system process, and the slave server runs the user processes. The memory and input-output devices are shared among all the processors,
and all the processors are connected to a common bus. This system is simple and reduces data sharing, so this system is called Asymmetric multiprocessing.

Virtualization and Threading

In this type of multiple processor scheduling, even a single CPU system acts as a multiple processor system. In a system with virtualization, the virtualization presents one or
more virtual CPUs to each of the virtual machines running on the system. It then schedules the use of physical CPUs among the virtual machines.

o Most virtualized environments have one host operating system and many guest operating systems, and the host operating system creates and manages the virtual
machines.
o Each virtual machine has a guest operating system installed, and applications run within that guest.
 o Each guest operating system may be assigned for specific use cases, applications, or users, including time-sharing or real-time operation.
o Any guest operating-system scheduling algorithm that assumes a certain amount of progress in a given amount of time will be negatively impacted by the virtualization.
o A time-sharing operating system tries to allot 100 milliseconds to each time slice to give users a reasonable response time. A given 100 millisecond time slice may take
much more than 100 milliseconds of virtual CPU time. Depending on how busy the system is, the time slice may take a second or more, which results in a very poor
response time for users logged into that virtual machine.
o The net effect of such scheduling layering is that individual virtualized operating systems receive only a portion of the available CPU cycles, even though they believe
they are receiving all cycles and scheduling all of those cycles. The time-of-day clocks in virtual machines are often incorrect because timers take no longer to trigger
than they would on dedicated CPUs.
o Virtualizations can thus undo the good scheduling algorithm efforts of the operating systems within virtual machines.

Real-Time CPU Scheduling.

real-time systems?

Systems that carry real-time tasks are known as real-time systems.

These tasks can be divided into two categories:
1. Soft real-time tasks: The task can be rescheduled.
2. Hard real-time tasks: The tasks need to be performed within a certain time period.
In this system, the scheduler is considered the most important component.
The scheduler aims to reduce the response time for each process.

Real-time scheduling algorithms:

In a simple real-time system, there might be no need for a scheduler, one task can simply call the next.
But for more complex real-time systems, that have a large but fixed number of tasks that do not function in pipeline function,
one may need static scheduling.
And for real-time systems where the workload keeps changing, one may need dynamic scheduling.

In dynamic scheduling two important question arises:

1. How to handle the overload?
To handle the overload these processes can be used:
the scheduling algorithm are classified as follows.

1. Static table-driven approaches:

These algorithms usually perform a static analysis associated with scheduling and capture the schedules that are advantageous. This helps in providing a
schedule that can point out a task with which the execution must be started at run time.

2. Static priority-driven preemptive approaches:

Similar to the first approach, these type of algorithms also uses static analysis of scheduling. The difference is that instead of selecting a particular schedule, it
 provides a useful way of assigning priorities among various tasks in preemptive scheduling.

3. Dynamic planning-based approaches:

Here, the feasible schedules are identified dynamically (at run time). It carries a certain fixed time interval and a process is executed if and only if satisfies the
time constraint.

4. Dynamic best effort approaches:

These types of approaches consider deadlines instead of feasible schedules. Therefore the task is aborted if its deadline is reached. This approach is used
widely is most of the real-time systems.

Advantages of Scheduling in Real-Time Systems:

• Meeting Timing Constraints: Scheduling ensures that real-time tasks are executed within their specified timing constraints. It guarantees that critical tasks
are completed on time, preventing potential system failures or losses.
• Resource Optimization: Scheduling algorithms allocate system resources effectively, ensuring efficient utilization of processor time, memory, and other
resources. This helps maximize system throughput and performance.
• Priority-Based Execution: Scheduling allows for priority-based execution, where higher-priority tasks are given precedence over lower-priority tasks. This
ensures that time-critical tasks are promptly executed, leading to improved system responsiveness and reliability.
• Predictability and Determinism: Real-time scheduling provides predictability and determinism in task execution. It enables developers to analyze and
guarantee the worst-case execution time and response time of tasks, ensuring that critical deadlines are met.
• Control Over Task Execution: Scheduling algorithms allow developers to have fine-grained control over how tasks are executed, such as specifying task
priorities, deadlines, and inter-task dependencies. This control facilitates the design and implementation of complex real-time systems.
Disadvantages of Scheduling in Real-Time Systems:
• Increased Complexity: Real-time scheduling introduces additional complexity to system design and implementation. Developers need to carefully analyze
task requirements, define priorities, and select suitable scheduling algorithms. This complexity can lead to increased development time and effort.
• Overhead: Scheduling introduces some overhead in terms of context switching, task prioritization, and scheduling decisions. This overhead can impact system
performance, especially in cases where frequent context switches or complex scheduling algorithms are employed.
• Limited Resources: Real-time systems often operate under resource-constrained environments. Scheduling tasks within these limitations can be challenging,
as the available resources may not be sufficient to meet all timing constraints or execute all tasks simultaneously.
• Verification and Validation: Validating the correctness of real-time schedules and ensuring that all tasks meet their deadlines require rigorous testing and
verification techniques. Verifying timing constraints and guaranteeing the absence of timing errors can be a complex and time-consuming process.
• Scalability: Scheduling algorithms that work well for smaller systems may not scale effectively to larger, more complex real-time systems. As the number of
tasks and system complexity increases, scheduling decisions become more challenging and may require more advanced algorithms or approaches.

Real Time Scheduling Algorithms processes that are to be scheduled.

p. The next characteristic is the
The foremost is that the processes are considered periodic i.e., the process will repeat itself after a fixed period of time. The period of a process is denoted by

processing time t i.e., the time for which the process requires the CPU within each period. In other words processing time refers to the burst time. The final characteristic is the deadline d, i.e., the
time before which the process must be serviced. In general the relationship between these three characteristics is

0≤t≤d≤p
Rate Monotonic Scheduling
In rate-monotonic scheduling algorithm a static priority policy with preemption is used. Whenever a high priority process arrives it will preempt a lower priority process. Every process gets the
priority according to its period. Lower the period higher is the priority. Also, the processing time remains the same in each period.

Example:

Suppose there are two processes, P1 and P2. The periods for P1 and P2 are 50 and 100. The processing times are t1 = 20 for P1 and t2 = 35 for P2. The deadline for each process requires that it
complete its CPU burst by the start of its next period.

Process Period/Deadline CPU Burst

P1 50 20

P2 100 35
Solution:

Since, it is mentioned that deadline for each process requires that it complete its CPU burst by the start of its next period, therefore, the deadline is same as the period of a process.

The priority of P1 is higher than P2 because P1 has smaller value for period. Therefore, at time 0, P1 will begin its execution. P1 will finish at 20 and then P2 will begin its execution (Refer Figure 1). At
time 50 P1’s second period will start. At the same time P2 has completed 30 nsec only. But since priority of P1 is higher, so P1 will preempt P2 and runs from 50-70. P2 completes the remaining 5
nsec from 70-75 but still meets its deadline of 100. The system remains idle till 100, when the 3rd period of P1 and second period of P2 will start and P1 will begin the execution at that time. The rest
of the execution will follow the same execution order as was from 0-100.

Figure 1: Rate Monotonic Scheduling Algorithm

Failure of rate Monotonic Scheduling:
Assume that process P1 has a period of p1 = 50 and a CPU burst of t1 = 25. For P2, the corresponding values are p2 = 80 and t2 = 35

Process Period CPU Burst

P1 50 25

P2 80 35
In the above example, if we use rate monotonic scheduling, the first process to begin execution will be P1 (lower time period). P1 will execute till 25nsec and then P2 will begin execution and run till
50 when P1 will begin its second period. Till time 50 P2 will finish 25nsec and will be left with 10nsec more. Now, the second peiord of P1 will be between 50 – 75. Now, P2 will requires 10nsec more
to finish but only 5nsec are left for the deadline (which is 80). Hence, P2 is not able to finish its execution within the deadline. Thus, Rate Monotonic Scheduling can not be used in this particular
scenario.

Earliest Deadline First Scheduling

The second algorithm under real time scheduling is Earliest Deadline First Scheduling. This algorithm assigns priority to the process based on the deadline. Earlier the deadline, higher is the priority.
Thus, the priorities keep on changing in this scheduling.

Example:

Assume that process P1 has a period of p1 = 50 and a CPU burst of t1 = 25. For P2, the corresponding values are p2 = 80 and t2 = 35

Process Period/Deadline CPU Burst

P1 50 25

P2 80 35
Solution:

Since, the deadline for P1 (50) is earlier than P2 (80) hence, the initial priority of P1 is higher than P2. So, P1 executes from 0-25 (Figure 2). Then, P2 starts at 25. At 50 P1 also arrives for second
period. At this point the deadline of P2(80) is earlier than the deadline of P1 (which is 100 for second period), hence, P2 will continue till 60. P1 starts at 60. P2 arrives for second period at 80. At this
point P1 is having higher priority because deadline for P1 is 100 whereas for P2 it is 160.

So, P1 continues will 85 after which P2 starts. At 100 P2 is preempted because priority of P1 is higher as the deadline for its third period is 150 (which is earlier than deadline of P1 which is 160). So P1
runs from 100-125 and then P2 completes its second period from 125 to 145. The system remains idle till 150 and then P1 resumes its next period.

Figure 2: Earliest deadline f

Deadlocks: System Model

A deadlock occurs when a set of processes is stalled because each process is holding a resource and waiting for another process to acquire another resource. In
the diagram below, for example, Process 1 is holding Resource 1 while Process 2 acquires Resource 2, and Process 2 is waiting for Resource 1.
 System Model :
• For the purposes of deadlock discussion, a system can be modeled as a collection of limited resources that can be divided int o different categories and allocated
to a variety of processes, each with different requirements.
• Memory, printers, CPUs, open files, tape drives, CD-ROMs, and other resources are examples of resource categories.
• By definition, all resources within a category are equivalent, and any of the resources within that category can equally satisfy a request from that category. If this
is not the case (i.e. if there is some difference between the resources within a category), then that category must be subdiv ided further. For example, the term
“printers” may need to be subdivided into “laser printers” and “color inkjet printers.”
• Some categories may only have one resource.
• The kernel keeps track of which resources are free and which are allocated, to which process they are allocated, and a queue of processes waiting for this
resource to become available for all kernel-managed resources. Mutexes or wait() and signal() calls can be used to control application-managed resources (i.e.
binary or counting semaphores. )
• When every process in a set is waiting for a resource that is currently assigned to another process in the set, the set is said to be deadlocked.
Operations :
In normal operation, a process must request a resource before using it and release it when finished, as shown below.
1. Request –
If the request cannot be granted immediately, the process must wait until the resource(s) required to become available. The system, for example, uses the
functions open(), malloc(), new(), and request ().
2. Use –
The process makes use of the resource, such as printing to a printer or reading from a file.
3. Release –
The process relinquishes the resource, allowing it to be used by other processes.
Necessary Conditions :
There are four conditions that must be met in order to achieve deadlock as follows.
1. Mutual Exclusion –
At least one resource must be kept in a non-shareable state; if another process requests it, it must wait for it to be released.
2. Hold and Wait –
A process must hold at least one resource while also waiting for at least one resource that another process is currently holding.

3. No preemption –
Once a process holds a resource (i.e. after its request is granted), that resource cannot be taken away from that process unt il the process voluntarily releases
it.

4. Circular Wait –
There must be a set of processes P0, P1, P2,…, PN such that every P[I] is waiting for P[(I + 1) percent (N + 1)]. (It is important to note that this condition
implies the hold-and-wait condition, but dealing with the four conditions is easier if they are considered separately).
Methods for Handling Deadlocks :
In general, there are three approaches to dealing with deadlocks as follows.
1. Preventing or avoiding deadlock by Avoid allowing the system to become stuck in a loop.
2. Detection and recovery of deadlocks, When deadlocks are detected, abort the process or preempt some resources.
3. Ignore the problem entirely.
4. To avoid deadlocks, the system requires more information about all processes. The system, in particular, must understand what resources a process will or may
request in the future. ( Depending on the algorithm, this can range from a simple worst-case maximum to a complete resource request and release plan for each
process. )
5. Deadlock detection is relatively simple, but deadlock recovery necessitates either aborting processes or preempting resources, neither of which is an appealing
option.
6. If deadlocks are not avoided or detected, the system will gradually slow down as more processes become stuck waiting for resources that the deadlock has
blocked and other waiting processes. Unfortunately, when the computing requirements of a real-time process are high, this slowdown can be confused with a
general system slowdown.
Deadlock Prevention :
Deadlocks can be avoided by avoiding at least one of the four necessary conditions: as follows.
Condition-1 :
Mutual Exclusion :
• Read-only files, for example, do not cause deadlocks.
• Unfortunately, some resources, such as printers and tape drives, require a single process to have exclusive access to them.
Condition-2 :
Hold and Wait :
To avoid this condition, processes must be prevented from holding one or more resources while also waiting for one or more others. There are a few possibilities
here:
• Make it a requirement that all processes request all resources at the same time. This can be a waste of system resources if a process requires one resource
early in its execution but does not require another until much later.
• Processes that hold resources must release them prior to requesting new ones, and then re-acquire the released resources alongside the new ones in a single
new request. This can be a problem if a process uses a resource to partially complete an operation and then fails to re -allocate it after it is released.
• If a process necessitates the use of one or more popular resources, either of the methods described above can result in starvation.
Condition-3 :
No Preemption :
When possible, preemption of process resource allocations can help to avoid deadlocks.
• One approach is that if a process is forced to wait when requesting a new resource, all other resources previously held by this process are implicitly released
(preempted), forcing this process to re-acquire the old resources alongside the new resources in a single request, as discussed previously.
• Another approach is that when a resource is requested, and it is not available, the system looks to see what other processes are currently using those resources
and are themselves blocked while waiting for another resource. If such a process is discovered, some of their resources may be preempted and added to the list
of resources that the process is looking for.
• Either of these approaches may be appropriate for resources whose states can be easily saved and restored, such as registers and memory, but they are
generally inapplicable to other devices, such as printers and tape drives.
Condition-4 :
Circular Wait :
• To avoid circular waits, number all resources and insist that processes request resources is strictly increasing ( or decreas ing) order.
• To put it another way, before requesting resource Rj, a process must first release all Ri such that I >= j.
• The relative ordering of the various resources is a significant challenge in this scheme.
Deadlock Avoidance :
• The general idea behind deadlock avoidance is to avoid deadlocks by avoiding at least one of the aforementioned conditions.
• This necessitates more information about each process AND results in low device utilization. (This is a conservative approach.)
• The scheduler only needs to know the maximum number of each resource that a process could potentially use in some algorithms. In more complex algorithms,
the scheduler can also use the schedule to determine which resources are required and in what order.
• When a scheduler determines that starting a process or granting resource requests will result in future deadlocks, the process is simply not started or the request
is denied.
• The number of available and allocated resources, as well as the maximum requirements of all processes in the system, define a resource allocation state.
Deadlock Detection :
• If deadlocks cannot be avoided, another approach is to detect them and recover in some way.
• Aside from the performance hit of constantly checking for deadlocks, a policy/algorithm for recovering from deadlocks must be in place, and when processes
must be aborted or have their resources preempted, there is the possibility of lost work.
Recovery From Deadlock :
There are three basic approaches to getting out of a bind:
1. Inform the system operator and give him/her permission to intervene manually.
2. Stop one or more of the processes involved in the deadlock.
3. Prevent the use of resources.
Approach of Recovery From Deadlock :
Here, we will discuss the approach of Recovery From Deadlock as follows.
Approach-1 :
Process Termination :
There are two basic approaches for recovering resources allocated to terminated processes as follows.
1. Stop all processes that are involved in the deadlock. This does break the deadlock, but at the expense of terminating more processes than are absolutely
necessary.
2. Processes should be terminated one at a time until the deadlock is broken. This method is more conservative, but it necessitates performing deadlock detection
after each step.
In the latter case, many factors can influence which processes are terminated next as follows.
1. Priorities in the process
2. How long has the process been running and how close it is to completion.
3. How many and what kind of resources does the process have? (Are they simple to anticipate and restore? )
4. How many more resources are required for the process to be completed?
5. How many processes will have to be killed?
6. Whether the process is batch or interactive.
Approach-2 :
Resource Preemption :
When allocating resources to break the deadlock, three critical issues must be addressed:
1. Selecting a victim –
Many of the decision criteria outlined above apply to determine which resources to preempt from which processes.
2. Rollback –
A preempted process should ideally be rolled back to a safe state before the point at which that resource was originally assigned to the process. Unfortunately,
determining such a safe state can be difficult or impossible, so the only safe rollback is to start from the beginning. (In other words, halt and restart the process.)
3. Starvation –
How do you ensure that a process does not go hungry because its resources are constantly being preempted? One option is to use a priority system and raise
the priority of a process whenever its resources are preempted. It should eventually gain a high enough priority that it will no longer be preempted.

Deadlock Characterization
A deadlock happens in operating system when two or more processes need some resource to complete their execution that is held by the other process.
A deadlock occurs if the four Coffman conditions hold true. But these conditions are not mutually exclusive. They are given as follows −

Mutual Exclusion

There should be a resource that can only be held by one process at a time. In the diagram below, there is a single instance of Resource 1 and it is held by Process 1 only.

Hold and Wait

A process can hold multiple resources and still request more resources from other processes which are holding them. In the diagram given below, Process 2 holds Resource 2
and Resource 3 and is requesting the Resource 1 which is held by Process 1.

No Preemption

A resource cannot be preempted from a process by force. A process can only release a resource voluntarily. In the diagram below, Process 2 cannot preempt Resource 1 from
Process 1. It will only be released when Process 1 relinquishes it voluntarily after its execution is complete.

Circular Wait

A process is waiting for the resource held by the second process, which is waiting for the resource held by the third process and so on, till the last process is waiting for a
resource held by the first process. This forms a circular chain. For example: Process 1 is allocated Resource2 and it is requesting Resource 1. Similarly, Process 2 is allocated
Resource 1 and it is requesting Resource 2. This forms a circular wait loop.
Methods for Handling Deadlocks
Deadlock detection, deadlock prevention and deadlock avoidance are the main methods for handling deadlocks. Details about these are given as follows −

Deadlock Detection

Deadlock can be detected by the resource scheduler as it keeps track of all the resources that are allocated to different processes. After a deadlock is detected, it can be handed
using the given methods −

• All the processes that are involved in the deadlock are terminated. This approach is not that useful as all the progress made by the processes is destroyed.
• Resources can be preempted from some processes and given to others until the deadlock situation is resolved.

Deadlock Prevention

It is important to prevent a deadlock before it can occur. So, the system checks each transaction before it is executed to make sure it does not lead to deadlock. If there is even
a slight possibility that a transaction may lead to deadlock, it is never allowed to execute.
Some deadlock prevention schemes that use timestamps in order to make sure that a deadlock does not occur are given as follows −

• Wait - Die Scheme

• In the wait - die scheme, if a transaction T1 requests for a resource that is held by transaction T2, one of the following two scenarios may occur −
o TS(T1) < TS(T2) - If T1 is older than T2 i.e T1 came in the system earlier than T2, then it is allowed to wait for the resource which will be free when T2 has
completed its execution.
o TS(T1) > TS(T2) - If T1 is younger than T2 i.e T1 came in the system after T2, then T1 is killed. It is restarted later with the same timestamp.
• Wound - Wait Scheme
• In the wound - wait scheme, if a transaction T1 requests for a resource that is held by transaction T2, one of the following two possibilities may occur −
o TS(T1) < TS(T2) - If T1 is older than T2 i.e T1 came in the system earlier than T2, then it is allowed to roll back T2 or wound T2. Then T1 takes the resource and
completes its execution. T2 is later restarted with the same timestamp.
o TS(T1) > TS(T2) - If T1 is younger than T2 i.e T1 came in the system after T2, then it is allowed to wait for the resource which will be free when T2 has completed
its execution.

Deadlock Avoidance

It is better to avoid a deadlock rather than take measures after the deadlock has occurred. The wait for graph can be used for deadlock avoidance. This is however only useful
for smaller databases as it can get quite complex in larger databases.
Wait for graph
The wait for graph shows the relationship between the resources and transactions. If a transaction requests a resource or if it already holds a resource, it is visible as an edge
on the wait for graph. If the wait for graph contains a cycle, then there may be a deadlock in the system, otherwise not.

Ostrich Algorithm

The ostrich algorithm means that the deadlock is simply ignored and it is assumed that it will never occur. This is done because in some systems the cost of handling the
deadlock is much higher than simply ignoring it as it occurs very rarely. So, it is simply assumed that the deadlock will never occur and the system is rebooted if it occurs by any
chance.

Deadlock Prevention

Deadlock Prevention in Operating System

let us take an example of a chair, as we know that chair always stands on its four legs. Likewise, for the deadlock problem, all the above given four conditions are needed. If
anyone leg of the chair gets broken, then definitely it will fall. The same is the situation with the deadlock if we become able to violate any condition among the four and do not
let them occur together then there can be prevented from the deadlock problem.

We will elaborate deadlock prevention approach by examining each of the four necessary conditions separately.

Mutual Exclusion

This condition must hold for non-sharable resources. For example, a printer cannot be simultaneously shared by several processes. In contrast, Sharable resources do not
require mutually exclusive access and thus cannot be involved in a deadlock. A good example of a sharable resource is Read-only files because if several processes attempt to
open a read-only file at the same time, then they can be granted simultaneous access to the file.

A process need not to wait for the sharable resource. Generally, deadlocks cannot be prevented by denying the mutual exclusion condition because there are some resources
that are intrinsically non-sharable.
Hold and Wait

Hold and wait condition occurs when a process holds a resource and is also waiting for some other resource in order to complete its execution. Thus if we did not want the
occurrence of this condition then we must guarantee that when a process requests a resource, it does not hold any other resource.

There are some protocols that can be used in order to ensure that the Hold and Wait condition never occurs:

• According to the first protocol; Each process must request and gets all its resources before the begining of its execution.
• The second protocol allows a process to request resources only when it does not occupy any resource.

Let us illustrate the difference between these two protocols:

We will consider a process that mainly copies data from a DVD drive to a file on disk, sorts the file, and then prints the results to a printer. If all the resources must be requested
at the beginning of the process according to the first protocol, then the process requests the DVD drive, disk file, and printer initially. It will hold the printer during its entire
execution, even though the printer is needed only at the end.

While the second method allows the process to request initially only the DVD drive and disk file. It copies the data from the DVD drive to the disk and then releases both the
DVD drive and the disk file. The process must then again request the disk file and printer. After copying the disk file to the printer, the process releases these two resources as
well and then terminates.
Disadvantages of Both Protocols
• Utilization of resources may be low, since resources may be allocated but unused for a long period. In the above-given example, for instance, we can release the DVD
drive and disk file and again request the disk file and printer only if we can be sure that our data will remain on the disk file. Otherwise, we must request all the
resources at the beginning of both protocols.
• There is a possibility of starvation. A process that needs several popular resources may have to wait indefinitely because at least one of the resources that it needs is
always allocated to some other process.

No Preemption
The third necessary condition for deadlocks is that there should be no preemption of resources that have already been allocated. In order to ensure that this condition does not
hold the following protocols can be used :
• According to the First Protocol: "If a process that is already holding some resources requests another resource and if the requested resources cannot be allocated to it,
then it must release all the resources currently allocated to it."
• According to the Second Protocol: "When a process requests some resources, if they are available, then allocate them. If in case the requested resource is not available
then we will check whether it is being used or is allocated to some other process waiting for other resources. If that resource is not being used, then the operating
system preempts it from the waiting process and allocate it to the requesting process. And if that resource is being used, then the requesting process must wait".

The second protocol can be applied to those resources whose state can be easily saved and restored later for example CPU registers and memory space, and cannot be applied
to resources like printers and tape drivers.

Circular Wait
The Fourth necessary condition to cause deadlock is circular wait, In order to ensure violate this condition we can do the following:
Assign a priority number to each resource. There will be a condition that any process cannot request for a lesser priority resource. This method ensures that not a single process
can request a resource that is being utilized by any other process and due to which no cycle will be formed.
Example: Assume that R5 resource is allocated to P1, if next time P1 asks for R4, R3 that are lesser than R5; then such request will not be granted. Only the request for resources
that are more than R5 will be granted.
 Deadlock Avoidance
Deadlock avoidance
In deadlock avoidance, the request for any resource will be granted if the resulting state of the system doesn't cause deadlock in the system. The state of the system will
continuously be checked for safe and unsafe states.

In order to avoid deadlocks, the process must tell OS, the maximum number of resources a process can request to complete its execution.

The simplest and most useful approach states that the process should declare the maximum number of resources of each type it may ever need. The Deadlock avoidance algorithm
examines the resource allocations so that there can never be a circular wait condition.

Safe and Unsafe States

The resource allocation state of a system can be defined by the instances of available and allocated resources, and the maximum instance of the resources demanded by the
processes.

A state of a system recorded at some random time is shown below.

Resources Assigned
Process Type 1 Type 2 Type 3 Type 4

A 3 0 2 2

B 0 0 1 1

C 1 1 1 0

D 2 1 4 0

Resources still needed

Process Type 1 Type 2 Type 3 Type 4

A 1 1 0 0

B 0 1 1 2

C 1 2 1 0

D 2 1 1 2

1. E = (7 6 8 4)
2. P = (6 2 8 3)
3. A = (1 4 0 1)
Above tables and vector E, P and A describes the resource allocation state of a system. There are 4 processes and 4 types of the resources in a system. Table 1 shows the instances
of each resource assigned to each process.

Table 2 shows the instances of the resources, each process still needs. Vector E is the representation of total instances of each resource in the system.

Vector P represents the instances of resources that have been assigned to processes. Vector A represents the number of resources that are not in use.

A state of the system is called safe if the system can allocate all the resources requested by all the processes without entering into deadlock.

If the system cannot fulfill the request of all processes then the state of the system is called unsafe.

The key of Deadlock avoidance approach is when the request is made for resources then the request must only be approved in the case if the resulting state is also a safe state.

Deadlock Detection and Recovery

In this approach, The OS doesn't apply any mechanism to avoid or prevent the deadlocks. Therefore the system considers that the deadlock will definitely occur. In order to get
rid of deadlocks, The OS periodically checks the system for any deadlock. In case, it finds any of the deadlock then the OS will recover the system using some recovery techniques.

The main task of the OS is detecting the deadlocks. The OS can detect the deadlocks with the help of Resource allocation graph.

In single instanced resource types, if a cycle is being formed in the system then there will definitely be a deadlock. On the other hand, in multiple instanced resource type graph,
detecting a cycle is not just enough. We have to apply the safety algorithm on the system by converting the resource allocation graph into the allocation matrix and request
matrix.

In order to recover the system from deadlocks, either OS considers resources or processes.

For Resource
Preempt the resource

We can snatch one of the resources from the owner of the resource (process) and give it to the other process with the expectation that it will complete the execution and will
release this resource sooner. Well, choosing a resource which will be snatched is going to be a bit difficult.

Rollback to a safe state

System passes through various states to get into the deadlock state. The operating system canrollback the system to the previous safe state. For this purpose, OS needs to
implement check pointing at every state.

The moment, we get into deadlock, we will rollback all the allocations to get into the previous safe state.

For Process

Kill a process

Killing a process can solve our problem but the bigger concern is to decide which process to kill. Generally, Operating system kills a process which has done least amount of work
until now.

Kill all process

This is not a suggestible approach but can be implemented if the problem becomes very serious. Killing all process will lead to inefficiency in the system because all the processes
will execute again from starting.