Process Scheduling

Process 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; any others
must wait until the CPU is free and can be rescheduled. The objective of
multiprogramming is to have some process running at all times, to
maximize CPU utilization.
• With multiprogramming, we try to use this time productively. Several
processes are kept in memory at one time. When one process has to wait,
the operating system takes the CPU away from that process and gives the
CPU to another process. This pattern continues. Every time one process has
to wait, another process can take over use of the CPU.
Process Scheduling
• The success of CPU scheduling depends on an observed property of
processes:
• process execution consists of a cycle of
• CPU execution and I/0 wait.
• Processes alternate between these two states. Process execution
begins with a CPU burst. That is followed by an I/O burst, which is
followed by another CPU burst, then another I/0 burst, and so on.
Eventually, the final CPU burst ends with a system request to
terminate execution.
Alternating sequence of CPU and I/O bursts
Histogram of CPU-burst durations
• The durations of CPU bursts have been measured extensively.
Although they vary greatly from process to process and from
computer to computer, they tend to have a frequency curve similar to
that shown in Figure
Histogram of CPU-burst durations
• The curve is generally characterized as exponential or hyper
exponential, with a large number of short CPU bursts and a small
number of long CPU bursts. An I/O-bound program typically has many
short CPU bursts. A CPU-bound program might have a few long CPU
bursts. This distribution can be important in the selection of an
appropriate CPU-scheduling algorithm.
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).
• The scheduler selects a process from the processes in memory that are
ready to execute and allocates the CPU to that process.
• Note that the ready queue is not necessarily a first-in, first-out (FIFO)
queue.
• A ready queue can be implementedd as a FIFO queue,priority queue, a
tree, or simply an unordered linked list.
• Conceptually, however, all the processes in the ready queue are lined up waiting for a chance to
run on the CPU. The records in the queues are generally process control blocks (PCBs) of the
processes.
Preemptive Scheduling
• CPU-scheduling decisions may take place under the following four
circumstances:
1. When a process switches from the running state to the waiting
state (for example, as the result of an I/0 request or an invocation
of wait for the termination of one of the child processes).
2. When a process switches from the running state to the ready state
(for example, when an interrupt occurs).
3. When a process switches from the waiting state to the ready state
(for example, at completion of I/0)
4. When a process terminates.
Preemptive Scheduling
• For situations 1 and 4, there is no choice in terms of scheduling. A new
process (if one exists in the ready queue) must be selected for execution.
There is a choice, however, for situations 2 and 3.
• When scheduling takes place only under circumstances 1 and 4, we say
that the scheduling scheme is nonpreemptive or cooperative; otherwise, it
is preemptive.
• Under nonpreemptive scheduling, once the CPU has been allocated to a
process, the process keeps the CPU until it releases the CPU either by
terminating or by switching to the waiting state.
• This scheduling method was used by Microsoft Windows 3.x;
• Windows 95 introduced preemptive scheduling, and all subsequent
versions of Windows operating systems have used preemptive scheduling.
Preemptive Scheduling
• In this scheduling, a process currently executing can be interrupted
and moved back to the ready queue if a higher-priority process
arrives or the CPU time slice for the process expires.
• It's used when the operating system needs to prioritize
responsiveness and fairness.
• It Ensures high-priority tasks are executed quickly.
• It may lead to higher overhead due to frequent context switching.
Preemptive Scheduling
• Let’s consider Round Robin (RR) scheduling:
• There are three processes:
• P1 (Burst time: 4 units)
• P2 (Burst time: 3 units)
• P3 (Burst time: 2 units)
• Time Quantum: 2 units
• Execution:
• First, P1 runs for 2 units → P2 runs for 2 units → P3 runs for 2 units.
• Then, P1 resumes for its remaining 2 units → P2 resumes for 1 unit.
• Here, processes are preempted after their time quantum expires or when a
higher-priority process arrives.
Non-Preemptive Scheduling
• In this scheduling, a process currently executing on the CPU runs until
it either finishes or voluntarily yields the CPU (e.g., by waiting for I/O).
• It’s used where tasks must be completed once they start without
interruption.
• Simpler to implement with less overhead.
• Can lead to starvation of lower-priority processe
Example of Non-Preemptive Scheduling
• Let’s consider First-Come, First-Served (FCFS) scheduling:
• There are three processes:
• P1 (Burst time: 4 units)
• P2 (Burst time: 3 units)
• P3 (Burst time: 2 units)
• Execution:
• P1 executes fully for 4 units → P2 executes fully for 3 units → P3
executes fully for 2 units.
• No process is interrupted until it completes.
Difference
Preemptive Scheduling Non-Preemptive Scheduling
CPU can be taken away from a process before it CPU is assigned to a process until it
completes execution. completes or voluntarily releases it.
Allows interruption of a running process. Once a process starts, it runs until it finishes.
Used in batch processing and simpler
Used in multitasking and time-sharing systems.
scheduling methods.
Example: Round Robin, Shortest Remaining Example: First Come First Serve (FCFS),
Time First (SRTF) Shortest Job Next (SJN)
Race Condition
• Preemptive scheduling can result in race conditions when data are
shared among several processes. Consider the case of two processes
that share data. While one process is updating the data, it is
preempted so that the second process can run. The second process
then tries to read the data, which are in an inconsistent state.
• A race condition occurs in a multi-threaded or multi-process system
when two or more processes access and modify shared data at the
same time, leading to unexpected or incorrect results. It happens
because the execution order of the processes is unpredictable.
Example: Two Processes Writing to the Same
File
• Imagine two processes, Process A and Process B, writing to the same
log file at the same time.
• Scenario (Without Synchronization)
• Process A opens log.txt, reads the content, and prepares to write "Process A executed\n".
• Process B also opens log.txt, reads the same content, and prepares to write "Process B executed\n".
• Both processes write to the file simultaneously, but since they don’t wait for each other:
• The content gets mixed up or overwritten.
• Some messages may be lost.
Why Does This Happen?
• Both processes access the file without locking it.
• They overwrite each other’s data, leading to incomplete or corrupted
output.
How to Prevent This?
• File Locking: The OS should lock the file so only one process can write
at a time.
• Synchronization Mechanisms: Use mutex, semaphores, or atomic
operations to prevent simultaneous access.
• Write Queue: Processes should wait in a queue instead of writing
simultaneously
Impact on Kernel Design
• Complexity: A preemptive kernel is harder to design because it needs
mechanisms to pause and resume tasks properly.
• Efficiency vs. Simplicity: Preemptive kernels make systems faster and
more responsive, but require careful handling of shared resources.
• Safety (Concurrency Issues): When tasks switch frequently, the OS
must prevent race conditions (e.g., two chefs using the same knife at
the same time).
Preemptive Scheduling
• Windows & Linux: Use a preemptive kernel (chef can be
interrupted).
• Older Operating Systems (DOS, early UNIX): Used non-preemptive
kernels (chef must finish before switching).
What Happens Inside the Kernel?
• The kernel is the core part of the operating system that manages
CPU, memory, and devices. It decides which process gets to use the
CPU and for how long.
• When we talk about preemption, we are asking:
"Can the OS interrupt a running process and give the CPU to another
process?"
Preemptive Kernel in Action (Modern OS like
Linux & Windows)
• In a preemptive kernel, the OS can pause a running process and
switch to another.
• Example:
• You are watching a video on YouTube.
• Suddenly, you get a WhatsApp call.
• The OS pauses the video player and gives CPU time to the calling app.
• After the call, the video resumes without restarting.
Preemptive Kernel in Action (Modern OS like
Linux & Windows)
• Why is this good?
• The system feels responsive because urgent tasks (incoming call) don’t wait.
• Multi-tasking works smoothly, allowing many apps to run at once.
• What’s the challenge?
• The OS must save the state of the paused process and restore it later.
• Frequent switching increases CPU overhead (context switching).
Non-Preemptive Kernel in Action (Older OS
like DOS, Early UNIX)
• In a non-preemptive kernel, once a process starts running, it keeps
the CPU until it finishes or voluntarily releases it.
• Example:
• You are printing a large document.
• Meanwhile, you try to open a browser.
• But the OS won’t let you use the browser until printing is completely done,.
Non-Preemptive Kernel in Action (Older OS
like DOS, Early UNIX)
• Why is this good?
• Simple to implement, no need to manage interruptions.
• Less CPU overhead, since the OS doesn’t need to keep switching task
• Why is this bad?
• The system feels slow and unresponsive.
• A single long task can block everything else (e.g., a stuck process can freeze the system).
Impact on Real-World Kernel Design
• Modern Operating Systems (Windows, Linux, macOS)
• Use a preemptive kernel for smooth multi-tasking.
• High-priority tasks (like responding to user input) always get CPU time
quickly.
• Requires synchronization mechanisms (mutex, semaphores) to handle shared
resources safely.
• Embedded Systems (Some IoT Devices, Old OS)
• May use a non-preemptive kernel because they run only one or two tasks at
a time.
• Example: A microwave oven OS doesn’t need preemption because it only
runs a few simple tasks (heating, timing, beeping).
Preemptive Scheduling
• Preemption makes modern OS faster and more efficient but needs
careful management.
• Non-preemptive systems are simpler but outdated for most general-
purpose computers.
• That’s why modern OS kernels prioritize preemptive scheduling to
ensure smooth performance.
Dispatcher
• Another component involved in the CPU-scheduling function is the
dispatcher. The dispatcher is the module that gives control of the
CPU’s core to the process selected by the CPU scheduler. This function
involves the following:
• Switching context from one process to another
• Switching to user mode
• Jumping to the proper location in the user program to resume that program
• The dispatcher should be as fast as possible, since it is invoked during
every context switch. The time it takes for the dispatcher to stop one
process and start another running is known as the dispatch latency.
The role of the dispatcher
Preemptive Scheduling
• The Mac OS X operating system for the Macintosh also uses
preemptive scheduling; previous versions of the Macintosh operating
system relied on cooperative scheduling. Cooperative scheduling is
the only method that can be used on certain hardware platforms,
because it does not require the special hardware (for example, a
timer) needed for preemptive scheduling.
• Preemptive scheduling incurs a cost associated with access to shared
data. Consider the case of two processes that share data. While one is
updating the data, it is preempted so that the second process can
run. The second process then tries to read the data, which are in an
inconsistent state. In such situations, we need new mechanisms to
coordinate access to shared data;
Preemptive Scheduling
• Preemption also affects the design of the operating-system kernel. During the processing of a
system call, the kernel may be busy with an activity on behalf of a process.
• Such activities may involve changing important kernel data (for instance, I/O queues).
• What happens if the process is preempted in the middle of these changes and the kernel (or the
device driver) needs to read or modify the same structure? Chaos ensues.
• Operating-system kernels can be designed as either nonpreemptive or preemptive.
• A nonpreemptive kernel will wait for a system call to complete or for a process to block while
waiting for I/O to complete to take place before doing a context switch. This scheme ensures that
the kernel structure is simple, since the kernel will not preempt a process while the kernel data
structures are in an inconsistent state. Unfortunately, this kernel-execution model is a poor one
for supporting real-time computing, where tasks must complete execution within a given time
frame.
• We need to explore scheduling demands of real-time systems. A preemptive kernel requires
mechanisms such as mutex locks to prevent race conditions when accessing shared kernel data
structures.
• Most modern operating systems are now fully preemptive when running in kernel mode
Preemptive Scheduling
• Because interrupts can, by definition, occur at any time, and because
they cannot always be ignored by the kernel, the sections of code
affected by interrupts must be guarded from simultaneous use.
• The operating system needs to accept interrupts at almost all times.
Otherwise, input might be lost or output overwritten. So that these
sections of code are not accessed concurrently by several processes,
they disable interrupts at entry and re-enable interrupts at exit.
• It is important to note that sections of code that disable interrupts do
not occur very often and typically contain few instructions
Scheduling Criteria
• Different CPU-scheduling algorithms have different properties, and the
choice of a particular algorithm may favor one class of processes over
another.
• In choosing which algorithm to use in a particular situation, we must
consider the properties of the various algorithms. Many criteria have been
suggested for comparing CPU-scheduling algorithms'. The criteria include
the following:
• CPU utilization
• Throughput
• Turnaround time
• Waiting time
• Response time
CPU utilization
• We want to keep the CPU as busy as possible.
• Conceptually, CPU utilization can range from 0 to 100 percent.
• In a real system, it should range from 40 percent (for a lightly loaded
system) to 90 percent (for a heavily loaded system).
• CPU utilization can be obtained by using the top command on Linux,
macOS, and UNIX systems.
Throughput
• One measure of work is the number of processes that are completed
per time unit, called throughput.
• For long processes, this rate may be one process over several
seconds; for short transactions, it may be tens of processes per
second
Turnaround time
• The interval from the time of submission of a process to the time of
completion is the turnaround time.
• Turnaround time is the sum of the periods spent waiting in the ready
queue, executing on the CPU, and doing I/O.
Waiting time
• The CPU-scheduling algorithm does not affect the amount of time
during which a process executes or does I/O.
• It affects only the amount of time that a process spends waiting in the
ready queue.
• Waiting time is the sum of the periods spent waiting in the ready
queue.
Response time
• Another measure is the time from the submission of a request until
the first response is produced. This measure, called response time, is
the time it takes to start responding, not the time it takes to output
the response.
Scheduling Criteria
• It is desirable to maximize CPU utilization and throughput and to
minimize turnaround time, waiting time, and response time. In most
cases, we optimize the average measure.
Scheduling Algorithms
• CPU scheduling deals with the problem of deciding which of the
processes in the ready queue is to be allocated the CPU’s core. There
are many different CPU scheduling algorithms.
1. First-Come, First-Served Scheduling
2. Shortest-Job-First Scheduling
3. Round-Robin Scheduling
4. Priority Scheduling
First-Come, First-Served Scheduling
• First-Come, First-Serve (FCFS) is the simplest CPU scheduling
algorithm, where processes are executed in the order they arrive. It
follows a FIFO (First-In, First-Out) queue mechanism:
• When a process enters the ready queue, its Process Control Block
(PCB) is added to the end of the queue.
• The CPU is allocated to the process at the head of the queue.
• Once the running process completes, it is removed from the queue,
and the next process gets the CPU.
• This method is non-preemptive, meaning once a process starts
execution, it cannot be interrupted until it finishes or requests I/O.
First-Come, First-Served Scheduling
• Consider the following set of processes that arrive at time 0, with the
length of the CPU burst given in milliseconds: Process Burst Time
P1 24
P2 3
P3 3

• If the processes arrive in the order P1, P2, P3, and are served in FCFS order,
we get the result shown in the following Gantt chart, which is a bar chart
that illustrates a particular schedule, including the start and finish times of
each of the participating processes.
First-Come, First-Served Scheduling
• 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.
• If the processes arrive in the order P2, P3, P1, however, the results
will be as shown in the following Gantt chart:

• The average waiting time is now (6 + 0 + 3)/3 = 3 milliseconds. This

reduction is substantial. This huge reduction in waiting time shows
that FCFS does not guarantee an optimal schedule and can lead to
inefficiencies.
First-Come, First-Served Scheduling
• Thus, the average waiting time under an FCFS policy is generally not
minimal and may vary substantially if the processes’ CPU burst times
vary greatly. These generates a convoy effect as all the other
processes wait for the one big process to get off the CPU. This effect
results in lower CPU and device utilization than might be possible if
the shorter processes were allowed to go first.
The Convoy Effect in FCFS
• In a dynamic system with a mix of CPU-bound and I/O-bound
processes, FCFS can lead to the convoy effect:
1. A CPU-bound process starts execution and holds the CPU for a long time.
2. Meanwhile, several I/O-bound processes finish their I/O operations and
enter the ready queue.
3. Since the CPU-bound process is still running, I/O-bound processes must
wait.
4. Once the CPU-bound process completes, the I/O-bound processes execute
quickly and move back to I/O queues.
5. At this point, the CPU sits idle until one of the I/O-bound processes
completes I/O and returns.
6. The cycle repeats, leading to poor CPU and device utilization.
FCFS and Non-Preemptive Nature
• Because FCFS is non-preemptive, a running process cannot be
interrupted. This is especially problematic in interactive systems,
where quick response times are needed. A single long process can
monopolize the CPU, leading to sluggish performance for all other
tasks.
Advantages of FCFS
• Simple Implementation: The algorithm is easy to implement using a
queue.
• Fair Scheduling: Ensures that every process is served in the order of
arrival, avoiding starvation.
• Minimal Overhead: No need for complex priority calculations or
preemption handling.
Disadvantages of FCFS
• High Average Waiting Time: Processes with shorter burst times may
have to wait for longer processes, increasing overall waiting time.
• Convoy Effect: A long-running process can block several shorter
processes, leading to inefficient CPU and device utilization.
• Poor Performance in Interactive Systems: Since FCFS is non-
preemptive, a process can monopolize the CPU, causing long delays
for interactive tasks.
First-Come, First-Served Scheduling
• While FCFS is easy to implement, it is inefficient due to high waiting
times and the convoy effect. It is not suitable for modern multitasking
environments, especially those requiring fairness and responsiveness.
Other algorithms like Shortest Job Next (SJN) or Round Robin (RR)
are preferred for better efficiency and lower waiting times.
Shortest-Job-First (SJF) Scheduling
• SJF is a CPU scheduling algorithm that selects the process with the
shortest next CPU burst time. If two processes have the same burst
time, FCFS is used as a tiebreaker. It is theoretically optimal,
minimizing average waiting time by prioritizing shorter jobs before
longer ones.
Shortest-Job-First (SJF) Scheduling
• Consider the following set of processes that arrive at time 0, with the
length of the CPU burst given in milliseconds:
Process Burst Time
P1 6
P2 8
P3 7
P4 3

• Average waiting time: (3 + 16 + 9 + 0) / 4 = 7 ms

Compared to FCFS (10.25 ms), SJF achieves a lower waiting time.
Shortest-Job-First (SJF) Scheduling
• The SJF scheduling algorithm is provably optimal, in that it gives the
minimum average waiting time for a given set of processes. Moving a short
process before a long one decreases the waiting time of the short process
more than it increases the waiting time of the long process. Consequently,
the average waiting time decreases.
• Although the SJF algorithm is optimal, it cannot be implemented at the
level of CPU scheduling, as there is no way to know the length of the next
CPU burst. 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.
Shortest-Job-First (SJF) Scheduling
• The next CPU burst is generally predicted as an exponential average
of the measured lengths of previous CPU bursts. We can define the
exponential average with the formula.
Limitations of SJF
• Prediction Challenge: Exact CPU burst lengths are unknown, requiring
estimation using an exponential averaging formula:
τ(n+1) = α t(n) + (1 - α) τ(n)
• Where t(n) is the last observed burst, τ(n) is the predicted value, and α (0 ≤
α ≤ 1) determines the weight of recent vs. historical data.
• That is, the value of tn contains our most recent information, while τn
stores the past history. The parameter α controls the relative weight of
recent and past history in our prediction. If α = 0, then τn+1 = τn, and
recent history has no effect (current conditions are assumed to be
transient). If α = 1, then τn+1 = tn, and only the most recent CPU burst
matters (history is assumed to be old and irrelevant). More commonly, α =
1/2, so recent history and past history are equally weighted. The initial τ0
can be defined as a constant or as an overall system average. Following
Figure shows an exponential average with α = 1/2 and τ0 = 10
Prediction of the length of the next CPU burst
Shortest-Job-First (SJF) Scheduling
• The SJF algorithm can be either preemptive or nonpreemptive.
• The choice arises when 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 what is left of the
currently executing process. A preemptive SJF algorithm will preempt
the currently executing process, whereas a nonpreemptive SJF
algorithm will allow the currently running process to finish its CPU
burst.
• Preemptive SJF scheduling is sometimes called shortest-remaining
time-first scheduling.
Preemptive vs. Nonpreemptive SJF
• Nonpreemptive SJF: The CPU is allocated until the process completes.
• Preemptive SJF (Shortest Remaining Time First - SRTF): If a newly
arrived process has a shorter burst than the remaining time of the
current process, preemption occurs.
Shortest-Job-First (SJF) Scheduling
Process Arrival Time Burst Time
P1 0 8
P2 1 4
P3 2 9
P4 3 5

• Gantt chart:
Shortest-Job-First (SJF) Scheduling
• 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 for this example is [(10 − 1) + (1
− 1) + (17 − 2) + (5 − 3)]/4 = 26/4 = 6.5 milliseconds. Nonpreemptive
SJF scheduling would result in an average waiting time of 7.75
milliseconds.
Drawbacks of SJF
• Starvation Risk: Longer processes may face indefinite delays if shorter
processes keep arriving.
• Implementation Difficulty: Predicting CPU burst times accurately is
challenging.
• SJF is highly efficient but requires careful burst-time estimation and
handling of process starvation.
Round-Robin Scheduling
• The round-robin (RR) scheduling algorithm 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.
• The CPU scheduler goes around the ready queue, allocating the CPU
to each process for a time interval of up to 1 time quantum.
Round-Robin Scheduling
• To implement RR scheduling, we again treat the ready queue as a FIFO
queue of processes. New processes are added to the tail of the ready
queue.
• The CPU scheduler picks the first process from the ready queue, sets a
timer to interrupt after 1 time quantum, and dispatches the process.
• One of two things will then happen. The process may have a CPU burst of
less than 1 time quantum. In this case, the process itself will release the
CPU voluntarily. The scheduler will then proceed to the next process in the
ready queue. 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.
Round-Robin Scheduling
• The average waiting time under the RR policy is often long. Consider the
following set of processes that arrive at time 0, with the length of the CPU burst
given in milliseconds:
Process Burst Time
P1 24
P2 3
P3 3

• 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 time quantum, and the CPU is given to the next process in the queue,
process P2. Process P2 does not need 4 milliseconds, so it quits before its time
quantum expires. The CPU is then given to the next process, process P3. Once
each process has received 1 time quantum, the CPU is returned to process P1 for
an additional time quantum.
Round-Robin Scheduling
• The resulting RR schedule is as follows

• 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.
Round-Robin Scheduling
• In the RR scheduling algorithm, no process is allocated the CPU for more
than 1 time quantum in a row (unless it is the only runnable process).
• If a process’s CPU burst exceeds 1 time quantum, that process is
preempted and is put back in the ready queue. The RR scheduling
algorithm is thus preemptive.
• If there are n processes in the ready queue and the time quantum is q,
then each process gets 1/n of the CPU time in chunks of at most q time
units. Each process must wait no longer than (n − 1) × q time units until its
next time quantum. For example, with five processes and a time quantum
of 20 milliseconds, each process will get up to 20 milliseconds every 100
milliseconds.
Round-Robin Scheduling
• The performance of the RR algorithm depends heavily on the size of the
time quantum.
• At one extreme, if the time quantum is extremely large, the RR policy is the
same as the FCFS policy. In contrast, if the time quantum is extremely small
(say, 1 millisecond), the RR approach can result in a large number of
context switches.
• Assume, for example, that we have only one process of 10 time units. If the
quantum is 12 time units, the process finishes in less than 1 time quantum,
with no overhead. If the quantum is 6 time units, however, the process
requires 2 quanta, resulting in a context switch. If the time quantum is 1
time unit, then nine context switches will occur, slowing the execution of
the process accordingly.
Round-Robin Scheduling
• How a smaller time quantum increases context switches
Round-Robin Scheduling
• We want the time quantum to be large with respect to the context
switch time.
• If the context-switch time is approximately 10 percent of the time
quantum, then about 10 percent of the CPU time will be spent in
context switching.
• In practice, most modern systems have time quanta ranging from 10
to 100 milliseconds. The time required for a context switch is typically
less than 10 microseconds; thus, the context-switch time is a small
fraction of the time quantum.
Round-Robin Scheduling
• Turnaround time also depends on the size of the time quantum.
• The average turnaround time of a set of processes does not
necessarily improve as the time-quantum size increases.
• In general, the average turnaround time can be improved if most
processes finish their next CPU burst in a single time quantum. For
example, given three processes of 10 time units each and a quantum
of 1 time unit, the average turnaround time is 29. If the time
quantum is 10, however, the average turnaround time drops to 20. If
context-switch time is added in, the average turnaround time
increases even more for a smaller time quantum, since more context
switches are required.
 Round-Robin Scheduling

Although the time quantum should be large compared with the context switch time, it should not be too large.
if the time quantum is too large, RR scheduling degenerates to an FCFS policy.
A rule of thumb is that 80 percent of the CPU bursts should be shorter than the time quantum.
Priority Scheduling
• The SJF algorithm is a special case of the general priority-scheduling
algorithm.
• 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 simply a priority algorithm where the priority (p) is
the inverse of the (predicted) next CPU burst. The larger the CPU
burst, the lower the priority, and vice versa.
Priority Scheduling
• Priority in scheduling in measured terms of high priority and low
priority.
• Priorities are generally indicated by some fixed range of numbers,
such as 0 to 7 or 0 to 4,095. However, there is no general agreement
on whether 0 is the highest or lowest priority. Some systems use low
numbers to represent low priority; others use low numbers for high
priority. This difference can lead to confusion.
• We will assume that low numbers represent high priority.
Priority Scheduling
• As an example, consider the following set of processes, assumed to
have arrived at time 0 in the order P1, P2, ···, P5, with the length of
the CPU burst given in milliseconds:
Process Burst Time Priority
P1 10 3
P2 1 1
P3 2 4
P4 1 5
P5 5 2
Priority Scheduling
• Using priority scheduling, we would schedule these processes according to the following
Gantt chart:

• The average waiting time is 8.2 milliseconds.

• Priorities can be defined either internally or externally.
• Internally defined priorities use some measurable quantity or quantities to compute the
priority of a process. For example, time limits, memory requirements, the number of
open files, and the ratio of average I/O burst to average CPU burst have been used in
computing priorities.
• External priorities are set by criteria outside the operating system, such as the
importance of the process, the type and amount of funds being paid for computer use,
the department sponsoring the work, and other, often political, factors.
Priority Scheduling
• Priority scheduling can be either preemptive or nonpreemptive.
• When a process arrives at the ready queue, its priority is compared
with the priority of the currently running process. 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.
• A nonpreemptive priority scheduling algorithm will simply put the
new process at the head of the ready queue.
Priority Scheduling
• A major problem with priority scheduling algorithms is indefinit blocking,
or starvation.
• A priority scheduling algorithm can leave some low priority processes
waiting indefinitely.
• In a heavily loaded computer system, a steady stream of higher-priority
processes can prevent a low-priority process from ever getting the CPU.
Generally, one of two things will happen. Either the process will eventually
be run (at 2 A.M. Sunday, when the system is finally lightly loaded), or the
computer system will eventually crash and lose all unfinished low-priority
processes.
• (Rumor has it that when they shut down the IBM 7094 at MIT in 1973,
they found a low-priority process that had been submitted in 1967 and
had not yet been run.)
Priority Scheduling
• A solution to the problem of indefinite blockage of low-priority
processes is aging. Aging involves gradually increasing the priority of
processes that wait in the system for a long time.
• For example, if priorities range from 127 (low) to 0 (high), we could
periodically (say, every second) increase the priority of a waiting
process by 1. Eventually, even a process with an initial priority of 127
would have the highest priority in the system and would be executed.
In fact, it would take a little over 2 minutes for a priority-127 process
to age to a priority-0 process
Priority Scheduling
• Another option is to combine round-robin and priority scheduling in
such a way that the system executes the highest-priority process and
runs processes with the same priority using round-robin scheduling.
Let’s illustrate with an example using the following set of processes,
with the burst time in milliseconds:
Process Burst Priority
Time
P1 4 3
P2 5 2
P3 8 2
P4 7 2
P5 3 3
Priority Scheduling
• Using priority scheduling with round-robin for processes with equal
priority, we would schedule these processes according to the following
Gantt chart using a time quantum of 2 milliseconds:

• In this example, process P4 has the highest priority, so it will run to

completion. Processes P2 and P3 have the next-highest priority, and they
will execute in a round-robin fashion. Notice that when process P2 finishes
at time 16, process P3 is the highest-priority process, so it will run until it
completes execution. Now, only processes P1 and P5 remain, and as they
have equal priority, they will execute in round-robin order until they
complete
Threads
Basic Concepts
• Maximum CPU
utilization obtained with
multiprogramming
• CPU–I/O Burst Cycle –
Process execution
consists of a cycle of
CPU execution and I/O
wait
• CPU burst followed by
I/O burst
• CPU burst distribution is
of main concern
Histogram of CPU-burst Times
CPU Scheduler
 Short-term scheduler selects from among the
processes in ready queue, and allocates the CPU to
one of them
 Queue may be ordered in various ways
 CPU scheduling decisions may take place when a
process:
1. Switches from running to waiting state
2. Switches from running to ready state
3. Switches from waiting to ready
4. Terminates
 Scheduling under 1 and 4 is nonpreemptive
 All other scheduling is preemptive
 Consider access to shared data
 Consider preemption while in kernel mode
 Consider interrupts occurring during crucial OS activities
Summary Dispatcher
• Dispatcher module gives control of the CPU
to the process selected by the short-term
scheduler; this involves:
• switching context
• switching to user mode
• jumping to the proper location in the user
program to restart that program
• Dispatch latency – time it takes for the
dispatcher to stop one process and start
another running
Scheduling Criteria
• CPU utilization – keep the CPU as busy as
possible
• Throughput – # of processes that complete
their execution per time unit
• Turnaround time – amount of time to execute
a particular process
• Waiting time – amount of time a process has
been waiting in the ready queue
• Response time – amount of time it takes from
when a request was submitted until the first
response is produced, not output (for time-
sharing environment)