Operating Systems

Multi-threaded
Programming
Module-2

Part -2
 Overview
• A thread is a basic unit of CPU utilization; it comprises a
thread ID, a program counter, a register set, and a stack.
• It shares with other threads belonging to the same process its
code section, data section, and other operating-system
resources, such as open files and signals.
• A traditional (or heavyweight) process has a single thread of
control. If a process has multiple threads of control, it can
perform more than one task at a time.

2
 Overview
• Figure illustrates the difference between a traditional single-
threaded process and a multithreaded process.

3
 Motivation for Multithreaded
Programming
• Most software applications that run on modern computers are
multithreaded. An application typically is implemented as a
separate process with several threads of control.
• A word processor may have a thread for displaying graphics,
another thread for responding to keystrokes from the user, and
a third thread for performing spelling and grammar checking in
the background.
• Applications can also be designed to leverage processing
capabilities on multicore systems. Such applications can
perform several CPU-intensive tasks in parallel across the
multiple computing cores.

4
 Motivation for Multithreaded
Programming
• A single application may be required to perform several similar
tasks. For example, a web server accepts client requests for
web pages, images, sound, and so forth. A busy web server
may have several (perhaps thousands of) clients concurrently
accessing it.
• Process creation is time consuming and resource intensive,
however.
• It is generally more efficient to use one process that contains
multiple threads. If the web-server process is multithreaded,
the server will create a separate thread that listens for client
requests.

5
 Motivation for Multithreaded
Programming

Multithreaded server architecture.

6
 Motivation for Multithreaded
Programming
• RPCs (remote procedure call)allow inter-process
communication by providing a communication mechanism
similar to ordinary function or procedure calls. Typically, RPC
servers are multithreaded. When a server receives a message, it
services the message using a separate thread. This allows the
server to service several concurrent requests.
• Most operating-system kernels are now multithreaded. Several
threads operate in the kernel, and each thread performs a
specific task, such as managing devices, managing memory, or
interrupt handling.
– For example, Solaris has a set of threads in the kernel specifically for
interrupt handling.
– Linux uses a kernel thread for managing the amount of free memory in
7 the system.
 Benefits
The benefits of multithreaded programming can be broken down
into four major categories:
Responsiveness
– Multithreading an interactive application may allow a program to
continue running even if part of it is blocked or is performing a
lengthy operation, thereby increasing responsiveness to the user.
– This quality is especially useful in designing user interfaces. For
instance, consider what happens when a user clicks a button that
results in the performance of a time-consuming operation. A
single-threaded application would be unresponsive to the user
until the operation had completed. In contrast, if the time-
consuming operation is performed in a separate thread, the
application remains responsive to the user.
8
 Benefits
Resource sharing
– Processes can only share resources through techniques such as
shared memory and message passing. Such techniques must be
explicitly arranged by the programmer.
– However, threads share the memory and the resources of the
process to which they belong by default.
– The benefit of sharing code and data is that it allows an
application to have several different threads of activity within the
same address space.

9
 Benefits
Economy
– Allocating memory and resources for process creation is costly.
Because threads share the resources of the process to which they
belong, it is more economical to create and context-switch
threads.
– Empirically gauging the difference in overhead can be difficult,
but in general it is significantly more time consuming to create
and manage processes than threads.
– In Solaris, for example, creating a process is about thirty times
slower than is creating a thread, and context switching is about
five times slower.

10
 Benefits
Scalability
• The benefits of multithreading can be even greater in a
multiprocessor architecture, where threads may be running
in parallel on different processing cores.
• A single-threaded process can run on only one processor,
regardless how many are available.

11
 Multicore Programming
• In response to the need for more computing performance,
single-CPU systems evolved into multi-CPU systems.
• A more recent, similar trend in system design is to place
multiple computing cores on a single chip. Each core appears
as a separate processor to the operating system.
• These systems are multicore or multiprocessor systems.
• Multithreaded programming provides a mechanism for more
efficient use of these multiple computing cores and improved
concurrency.

12
 • An application with four threads. On a system with a single
computing core, concurrency merely means that the execution of the
threads will be interleaved over time, because the processing core is
capable of executing only one thread at a time.
• On a system with multiple cores, however, concurrency means that
the threads can run in parallel, because the system can assign a
separate thread to each core.
single core
Concurrent execution on a single-core system .

core 1

core 2
Parallel execution on a multicore system
13
 Parallelism and Concurrency
• Notice the distinction between parallelism and concurrency in
this discussion. A system is parallel if it can perform more than
one task simultaneously.
• In contrast, a concurrent system supports more than one task by
allowing all the tasks to make progress. Thus, it is possible to
have concurrency without parallelism.
• Before the advent of SMP and multicore architectures, most
computer systems had only a single processor.

14
 Parallelism and Concurrency
• CPU schedulers were designed to provide the illusion of
parallelism by rapidly switching between processes in the
system, thereby allowing each process to make progress. Such
processes were running concurrently, but not in parallel.
• As systems have grown from tens of threads to thousands of
threads, CPU designers have improved system performance by
adding hardware to improve thread performance.
• Modern Intel CPUs frequently support two threads per core,
while the Oracle T4 CPU supports eight threads per core.
• This support means that multiple threads can be loaded into the
core for fast switching. Multicore computers will no doubt
continue to increase in core counts and hardware thread
15 support.
 Multithreading Models
• Support for threads may be provided either at the user level, for
user threads, or by the kernel, for kernel threads.
• User threads are supported above the kernel and are managed
without kernel support, whereas kernel threads are supported
and managed directly by the operating system.
• Virtually all contemporary operating systems— including
Windows, Linux, Mac OS X, and Solaris— support kernel
threads.
• A relationship must exist between user threads and kernel
threads

16
 Multithreading Models
• Three common ways of establishing such a relationship:
• the many-to-one model,
• the one-to-one model,
• the many-to- many model.

17
 Many-to-One Model
• The many-to-one model maps many user-level threads to one
kernel thread.
• Thread management is done by the thread library in user space,
so it is efficient.
• The entire process will block if a thread makes a blocking
system call. Also, because only one thread can access the kernel
at a time, multiple threads are unable to run in parallel on
multicore systems.
• Green threads — a thread library available for Solaris systems
and adopted in early versions of Java— used the many-to-one
model.
• Very few systems continue to use the model because of its
18 inability to take advantage of multiple processing cores.
 Many-to-One Model

Many-to-one model
19
 One-to-One Model
• The one-to-one model maps each user thread to a kernel thread.
• It provides more concurrency than the many-to-one model by
allowing another thread to run when a thread makes a blocking
system call.
• It also allows multiple threads to run in parallel on
multiprocessors.
• The only drawback to this model is that creating a user thread
requires creating the corresponding kernel thread. Because the
overhead of creating kernel threads can burden the
performance of an application, most implementations of this
model restrict the number of threads supported by the system.
• Linux, along with the family of Windows operating systems,
20 implement the one-to-one model.
 One-to-One Model

21
 Many-to-Many Model
• The many-to-many model multiplexes many user-level threads
to a smaller or equal number of kernel threads.
• The number of kernel threads may be specific to either a
particular application or a particular machine.
• Developers can create as many user threads as necessary, and
the corresponding kernel threads can run in parallel on a
multiprocessor. Also, when a thread performs a blocking
system call, the kernel can schedule another thread for
execution.
• One variation on the many-to-many model still multiplexes
many user- level threads to a smaller or equal number of kernel
threads but also allows a user-level thread to be bound to a
22 kernel thread. This variation is also called the two-level model.
 Many-to-Many Model

Fig: Many-to-many model Fig: Two-level model

Examples
23 •HP-UX, Tru64 UNIX
 Thread Libraries
• A thread library provides the programmer with an API for
creating and managing threads. There are two primary ways of
implementing a thread library.
• The first approach is to provide a library entirely in user space
with no kernel support. All code and data structures for the
library exist in user space. This means that invoking a function
in the library results in a local function call in user space and
not a system call.
• The second approach is to implement a kernel-level library
supported directly by the operating system. In this case, code
and data structures for the library exist in kernel space.
Invoking a function in the API for the library typically results
in a system call to the kernel.
24
 Thread Libraries
• Three main thread libraries:
– POSIXP threads
– Win32 and
– Java.

25
 Thread Libraries
• Pthreads, the threads extension of the POSIX standard, may be
provided as either a user-level or a kernel-level library.
• The Windows thread library is a kernel-level library available
on Windows systems.
• The Java thread API allows threads to be created and managed
directly in Java programs. However, because in most instances
the JVM is running on top of a host operating system, the Java
thread API is generally implemented using a thread library
available on the host system.
• This means that on Windows systems, Java threads are
typically implemented using the Windows API; UNIX and
Linux systems often use Pthreads.
26
 Thread Libraries
• For POSIX and Windows threading, any data declared globally
— that is, declared outside of any function — are shared
among all threads belonging to the same process.
• Two general strategies for creating multiple threads:
• Asynchronous threading
• Synchronous threading.
• In asynchronous threading, once the parent creates a child
thread, the parent resumes its execution, so that the parent and
child execute concurrently.
• Each thread runs independently of every other thread, and the
parent thread need not know when its child terminates.
Because the threads are independent, there is typically little
27 data sharing between threads.
 Thread Libraries
• Synchronous threading occurs when the parent thread creates
one or more children and then must wait for all of its children
to terminate before it resumes —the so-called fork-join
strategy.
• Here, the threads created by the parent perform work
concurrently, but the parent cannot continue until this work has
been completed. Once each thread has finished its work, it
terminates and joins with its parent. Only after all of the
children have joined can the parent resume execution.
• Typically, synchronous threading involves significant data
sharing among threads. For example, the parent thread may
combine the results calculated by its various children.
28
 Pthreads
• Pthreads refers to the POSIX standard (IEEE 1003.1c)
defining an API for thread creation and synchronization. This
is a speciflcation for thread behavior, not an implementation.
• Numerous systems implement the Pthreads specification; most
are UNIX-type systems, including Linux, Mac OS X, and
Solaris.
• The C program demonstrates the basic Pthreads API for
constructing a multithreaded program that calculates the
summation of a non- negative integer in a separate thread.

29
30
 • This program demonstrates the basic Pthreads API for
constructing a multithreaded program that calculates the
summation of a non- negative integer in a separate thread.
• In a Pthreads program, separate threads begin execution in a
specified function. In program, this is the runner() function.
• When this program begins, a single thread of control begins in
main(). After some initialization, main() creates a second
thread that begins control in the runner() function. Both threads
share the global data sum.
• Let’s look more closely at this program. All Pthreads programs
must include the pthread.h header file.

31
 Win32 threads
• Implements the one-to-one mapping
• Each thread contains
• A thread id
• Register set
• Separate user and kernels tacks
• Private data storage area
• The register set, stacks, and private storage area are known as
the context of the threads The primary data structures of a
thread include:
 ETHREAD (executive thread block)
 KTHREAD (kernel thread block)
 TEB (thread environment block)
32
 Java Threads
• Threads are the basic model of program-executionin
• Java program and
• Java language.
• The API provides a rich set of features for the creation and
management of threads.
• All Java programs comprise at least a single thread of control.
• Two techniques for creating threads:
– Create a new class that is derived from the Thread class and override its run() method.
– Define a class that implements the Runnable interface. The Runnable interface is defined
as follows:

33
 THREADING ISSUES
• fork() and exec() System-calls
• fork() is used to create a separate, duplicateprocess.
• If one thread in a program calls fork(),then
– Some systems duplicates all threads and
– Other systems duplicate only the thread that invoked the forkO.
• If a thread invokes the exec(), the program specified in the
parameter to exec() will replace the entire process including all
threads.

34
 THREADING ISSUES
Thread Cancellation
•This is the task of terminating a thread before it has completed.
•Target thread is the thread that is to be cancelled
•Thread cancellation occurs in two different cases:
– Asynchronous cancellation: One thread immediately terminates
the target thread.
– Deferred cancellation: The target thread periodically checks
whether it should be terminated..

35
 Signal Handling
•In UNIX, a signal is used to notify a process that a particular event has
occurred.
•All signals follow this pattern:
1. A signal is generated by the occurrence of a certain event.
2. A generated signal is delivered to a process.
3. Once delivered, the signal must be handled.
•A signal handler is used to process signals.

36
 • A signal may be received either synchronously or asynchronously,
depending on the source.
– Synchronous signals
• Delivered to the same process that performed the operation causing
the signal.
• E.g. illegal memory access and division by 0.
– Asynchronoussignals
• Generated by an event external to a running process.
• E.g. user terminating a process with specific keystrokes<ctrl><c>.
• Every signal can be handled by one of two possible handlers:
• A Default SignalHandler
– Run by the kernel when handling the signal.
• A User-defined SignalHandler
– Overrides the default signal handler.
37
 • In single-threaded programs, delivering signals is simple (since
signals are always delivered to a process).
• In multithreaded programs, delivering signals is more complex.
Then, the following options exist:
1. Deliver the signal to the thread to which the signal applies.
2. Deliver the signal to every thread in process
3. Deliver the signal to certain threads in the process.
4. Assign a specific thread to receive all signals for the process.

38
 THREAD POOLS
• The basic idea is to
• create a no. of threads at process-startup and
• place the threads into a pool (where they sit and wait for
work).
• Procedure:
• When a server receives a request, it awakens a thread
from the pool.
• If any thread is available, the request is passed to it for
service.
• Once the service is completed, the thread returns to the
pool.
39
 THREAD POOLS
• Advantages:
• Servicing a request with an existing thread is usually
faster than waiting to create a thread.
• The pool limits the no. of threads that exist at any one
point.
• No. of threads in the pool can be based on
actors such as
• no. of CPUs
• amount of memory and
• expected no. of concurrent client-requests.

40
 THREAD SPECIFIC DATA
• Threads belonging to a process share the data of the process.
• This sharing of data provides one of the benefits of multithreaded
programming.
• In some circumstances, each thread might need its own copy of
certain data. We will call such data thread-specific data.
• For example, in a transaction-processing system, we might service
each transaction in a separate thread.
• Furthermore, each transaction may be assigned a unique identifier.
To associate each thread with its unique identifier, we could use
thread-specific data.

41
 SCHEDULER ACTIVATIONS
• Both M:M and Two-level models require communication to maintain
the appropriate number of kernel threads allocated to the application.
• Scheduler activations provide upcalls a communication mechanism
from the kernel to the thread library
• This communication allows an application to maintain the correct
number kernel threads
• One scheme for communication between the user-thread library and
the kernel is known as scheduler activation.

42
 PROCESS SCHEDULING
Basic Concepts
•In a single-processor system,
– Only one process may run at a time.
– Other processes must wait until the CPU is
rescheduled.
•Objective of multiprogramming:
– To have some process running at all times, in order
to maximize CPU utilization.

43
 PROCESS SCHEDULING
CPU– I/O Burst Cycle
•The success of CPU scheduling depends on an observed property
of processes: process execution consists of a cycle of CPU
execution and I/O 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/O burst,
and so on.
•The final CPU burst ends with a system request to terminate
execution.

44
45
 • 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.
• The curve is generally characterized as exponential or hyperexponential, 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.

46
 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 ready queue is not necessarily a first-in, first-out (FIFO)
queue. A ready queue can be implemented as a FIFO queue, a
priority queue, a tree, or simply an unordered linked list.
• 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.

47
 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/O request or an invocation of wait() for the
termination of a child process)
2. When a process switches from the running state to the ready state (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/O)
4. When a process terminates
•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.
48 Otherwise, it is preemptive.
 Non Preemptive 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.

Preemptive Scheduling
– This is driven by the idea of prioritized computation.
– Processes that are runnable may be temporarily suspended
– Disadvantages:
• Incurs a cost associated with access to shared-data.
• Affects the design of the OS kernel.

49
 Dispatcher
• The dispatcher is the module that gives control of the CPU to
the process selected by the short-term scheduler. This function
involves the following:
– Switching context
– Switching to user mode
– Jumping to the proper location in the user program to restart that
program
• The dispatcher should be as fast as possible, since it is invoked
during every process switch.
• The time it takes for the dispatcher to stop one process and
start another running is known as the dispatch latency.

50
 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. Which characteristics are used for
comparison can make a substantial difference in which
algorithm is judged to be best.

51
 The criteria include the following:
1.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 used system).
2.Throughput: If the CPU is busy executing processes, then work is being
done. 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
per hour; for short transactions, it may be ten processes per second.
3. Turnaround time. This is the important criterion which tells how long it
takes to execute that process. 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 to get into memory, waiting in the ready
queue, executing on the CPU, and doing I/0.

52
 4. Waiting time: The CPU-scheduling algorithm does not affect the
amount of time during which a process executes or does I/0, 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.
5. Response time : In an interactive system, turnaround time may not
be the best criterion. Often, a process can produce some output
fairly early and can continue computing new results while previous
results are being output to the user. Thus, 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. The
turnaround time is generally limited by the speed of the output
device.
53
 Scheduling Algorithms
• CPU scheduling deals with the problem of deciding which of
the processes in the ready-queue is to be allocated the CPU.
• Following are some scheduling algorithms:
1. FCFS scheduling (First Come First Served)
2. Round Robin scheduling
3. SJF scheduling (Shortest Job First)
4. SRT scheduling
5. Priority scheduling
6. Multilevel Queue scheduling and
7. Multilevel Feedback Queue scheduling

54
 First-Come, First-Served Scheduling
• The simplest CPU-scheduling algorithm is the first-come,
first-served (FCFS) scheduling algorithm.
• The process that requests the CPU first is allocated the CPU
first. The implementation of the FCFS policy is easily managed
with a FIFO queue.
• When a process enters the ready queue, its PCB is linked onto
the tail of the queue.
• When the CPU is free, it is allocated to the process at the head
of the queue.
• The running process is then removed from the queue.

55
 First-Come, First-Served Scheduling
• Advantage:
1. Code is simple to write & understand.
• Disadvantages:
1. Convoy effect: All other processes wait for one
big process to get off the CPU.
2. Non-preemptive (a process keeps the CPU until it
releases it).
3. Not good for time-sharing systems.
4. The average waiting time under the FCFS policy
is often quite long.
56
 First-Come, First-Served Scheduling
• The following set of processes that arrive at time 0, with the length of the
Process Burst Time
CPU burst given in milliseconds:
P1 24
P2 3
P3 3

• If the processes arrive in the order P1, P2, P3, and are served in FCFS order,
The Gantt chart, which is a bar chart that illustrates a particular schedule,
including the start and finish times of each of the participating processes:

• 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.
57
 First-Come, First-Served Scheduling
• 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. 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.
• There is 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.

58
 Shortest-Job-First Scheduling
• The CPU is assigned to the process that has the smallest next CPU
burst.
• If two processes have the same length CPU burst, FCFS scheduling
is used to break the tie.
• For long-term scheduling in a batch system, we can use the process
time limit specified by the user, as the ‘length’
• SJF can't be implemented at the level of short-term scheduling,
because there is no way to know the length of the next CPU burst
• Advantage:
• The SJF is optimal, i.e. it gives the minimum average waiting time for a given
set of processes.
• Disadvantage:
• Determining the length of the next CPU burst .
59
 Shortest-Job-First Scheduling
• SJF algorithm may be either 1) non-preemptive or 2)preemptive.
• Non preemptive SJF
– The current process is allowed to finish its CPU burst.
• Preemptive SJF
– If the new process has a shorter next CPU burst than what is left of the
executing process, that process is preempted. It is also known as SRTF
scheduling (Shortest-Remaining-Time-First).
• Example (for non-preemptive SJF): Consider the following set of
processes, with the length of the CPU-burst time given in
milliseconds. Process Burst Time
P1 6
P2 8
P3 7
P4 3

60
 Shortest-Job-First Scheduling
• Using SJF scheduling, we would schedule these processes according
to the following Gantt chart:

• The waiting time is 3 milliseconds for process P1, 16 milliseconds for

process P2, 9 milliseconds for process P3, and 0 milliseconds for
process P4. Thus, the average waiting time is (3 + 16 + 9 + 0)/4 = 7
milliseconds.
• preemptive SJF/SRTF: Consider the following set of processes,
with the length of the CPU- burst time given in milliseconds.
Process Arrival Time Burst Time
P1 0 8
P2 1 4
P3 2 9
P4 3 5
61
 Shortest-Job-First Scheduling
• If the processes arrive at the ready queue at the times shown and need
the indicated burst times, then the resulting preemptive SJF schedule is
as depicted in the following Gantt chart:

• 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.
• Non-preemptive SJF scheduling would result in an average waiting
62 time of 7.75 milliseconds.
 Priority Scheduling
• A priority is associated with each process.
• The CPU is allocated to the process with the highes tpriority.
• Equal-priority processes are scheduled in FCFS order.
• Priorities can be defined either internally or externally.
– Internally-defined priorities.
• Use some measurable quantity to compute the priority of a
process.
• For example: time limits, memory requirements, no. of open
files.
– Externally-defined priorities.
• Set by criteria that are external to the OS For example:
• importance of the process, political factors
63
 Priority Scheduling
• Priority scheduling can be either preemptive or non-preemptive.
• Preemptive
– The CPU is preempted if the priority of the newly arrived process is higher than
the priority of the currently running process.
• Non Preemptive
– The new process is put at the head of the ready-queue
• Advantage:
• Higher priority processes can be executed first.
• Disadvantage:
• Indefinite blocking, or starvation where low-priority processes are left
waiting indefinitely for CPU.
• Solution: Aging is a technique of increasing -For example, if priorities
range from 127 (low) to 0 (high), we could increase the priority of a
waiting process by 1 every 15 minutes
64
 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:
Proces Burst Priorit
s Time y
P1 10 3
P2 1 1
P3 2 4
P4 1 5
P5 5 2
• Using priority scheduling, we would schedule these processes
according to the following Gantt chart:

• The average waiting time is 8.2 milliseconds.

65
 Round-Robin Scheduling
• The round-robin (RR) scheduling algorithm is designed especially
for time- sharing systems.
• It 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.
• To implement RR scheduling, 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
66 a timer to interrupt after 1 time quantum, and dispatches the process.
 Round-Robin Scheduling
• One of two things will then happen.
• The process may have a CPU burst of less than 1 time quantum. The
process itself will release the CPU voluntarily. The scheduler will
then proceed to the next process in the ready queue.
• 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.
• Advantage:
• Higher average turnaround than SJF.
• Disadvantage:
• The average waiting time under the RR policy is often long
67
 Round-Robin Scheduling
• 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, it is preempted after the first time quantum,
process P2. Process P2 does not need 4 milliseconds, so it quits
before its time quantum expires. The next process P3. Once each
process has received 1 time quantum, the CPU is returned to process
P1 for an additional time quantum. The resulting RR schedule is as
follows:

68
 Round-Robin Scheduling
• The average waiting time for this schedule. P1 waits for 6
milliseconds (10 - 4), P2 waits for 4 milliseconds, and P3 waits for 7
milliseconds. Thus, the average waiting time is 17/3 = 5.66
milliseconds.

• The 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.
69
 • The performance of algorithm depends heavily on the size of the
time quantum.
– If time quantum=very large, RR policy is the same as the FCFSpolicy.
– If time quantum=very small, RR approach appears to the users as though each
of n processes has its own processor running at l/n the speed of the real
processor.
• In software, we need to consider the effect of context switching on
the performance of RR scheduling
– Larger the time quantum for a specific process time, less time is spend on
context switching.
– The smaller the time quantum, more overhead is added for the purpose of
context- switching.

70
 • 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, 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.

71
 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.
• 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, 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.
• 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
72 shorter than the time quantum.
 Round-Robin Scheduling

73
 Multilevel Queue Scheduling
• Useful for situations in which processes are easily classified into
different groups.
• For example, a common division is made between
– Foreground (or interactive) processes and
– Background (or batch) processes.
• These two types of processes have different response-time
requirements and so may have different scheduling needs.
• In addition, foreground processes may have priority (externally
defined) over background processes.
• The ready-queue is partitioned into several separate queues
• The processes are permanently assigned to one queue, generally
based on some property of the process, such as memory size, process
priority, or process type.
74
 Multilevel Queue Scheduling
• Each queue has its own scheduling algorithm.
• For example, separate queues might be used for foreground
and background processes. The foreground queue might be
scheduled by an RR algorithm, while the background queue is
scheduled by an FCFS algorithm.
• In addition, there must be scheduling among the queues, which
is commonly implemented as fixed-priority preemptive
scheduling. For example, the foreground queue may have
absolute priority over the background queue.

75
 Multilevel Queue Scheduling
• An example of a multilevel queue scheduling algorithm with five
queues, listed below in order of priority:
1. System processes
2. Interactive processes
3. Interactive editing processes
4. Batch processes
5. Student processes

76
 Multilevel Queue Scheduling
• Each queue has absolute priority over lower-priority queues. No
process in the batch queue could run unless the queues for system
processes, interactive processes, and interactive editing processes
were all empty. If an interactive editing process entered the ready
queue while a batch process was running, the batch process would be
preempted.
• Another possibility is to time-slice among the queues. Each queue
gets a certain portion of the CPU time, which it can then schedule
among its various processes. For instance, in the foreground–
background queue, the foreground queue can be given 80 percent of
the CPU time for RR scheduling among its processes, while the
background queue receives 20 percent of the CPU to give to its
processes on an FCFS basis.

77
 Multilevel Feedback Queue Scheduling
• A process may move between queues
• The basic idea: Separate processes according to the features of their
CPU bursts.
For example
– If a process uses too much CPU time, it will be moved to a lower-
priority queue. This scheme leaves I/O-bound and interactive
processes in the higher-priority queues.
– If a process waits too long in a lower-priority queue, it may be
moved to a higher-priority queue This form of aging prevents
starvation.

78
 Multilevel Feedback Queue Scheduling
• A multilevel feedback queue scheduler is defined by the following
parameters:
1. The number of queues.
2. The scheduling algorithm for each queue.
3. The method used to determine when to upgrade a process to a
higher priority queue.
4. The method used to determine when to demote a process to a
lower priority queue.
5. The method used to determine which queue a process will enter
when that process needs service

79
 Multilevel Feedback Queue Scheduling
• For example, consider a multilevel feedback queue scheduler with
three queues, numbered from 0 to 2.
– The scheduler first executes all processes in queue 0. Only when queue 0
is empty will it execute processes in queue 1.
– Similarly, processes in queue 2 will be executed only if queues 0 and 1
are empty.
– A process that arrives for queue 1 will preempt a process in queue 2. A
process in queue 1 will in turn be preempted by a process arriving for
queue 0.
A process in queue 0 is given a time quantum of 8 milliseconds. If it does
not finish within this time, it is moved to the tail of queue 1.
If queue 0 is empty, the process at the head of queue 1 is given a quantum of
16 milliseconds. If it does not complete, it is preempted and is put into
queue 2.
Processes in queue 2 are run on an FCFS basis but are run only when queues
80 0 and 1 are empty.
 Multilevel Feedback Queue Scheduling

81
 MULTIPLE PROCESSOR
SCHEDULING
• If multiple CPUs are available, the scheduling problem becomes more
complex.
Two approaches for Multiple Processor Scheduling:
Asymmetric Multiprocessing
– A master server is a single processor responsible for all scheduling decisions,
I/O processing and other system activities.
– The other processors execute only user code.
– Advantage: This is simple because only one processor accesses the system data
structures, reducing the need for data sharing.
Symmetric Multiprocessing
– Each processor is self-scheduling.
– To do scheduling, the scheduler for each processor
– Examines the ready-queue and
– Selects a process to execute.
Restriction: We must ensure that two processors do not choose the same process
82 and that processes are not lost from the queue.
 • Processor Affinity
In SMP systems,
• Migration of processes from one processor to another are avoided
and
• Instead processes are kept running on same processor. This is known
as processor affinity.
• Two forms of Affinity:
– Soft Affinity
• When an OS try to keep a process on one processor because of policy, but
cannot guarantee it will happen.
• It is possible for a process to migrate between processors.
– Hard Affinity
• When an OS have the ability to allow a process to specify that it is not to
migrate to other processors. Eg: Solaris OS
83
 • Load Balancing
– This attempts to keep the workload evenly distributed across all
processors in an SMP system.
• Two approaches of Load balancing:
– Push Migration
• A specific task periodically checks the load on each processor and if
it finds an imbalance, it evenly distributes the load to idle
processors.
– Pull Migration
• An idle processor pulls a waiting task from a busy processor.

84
 • Symmetric Multithreading
• Create multiple logical processors on the same physical processor.
• Present a view of several logical processors to the OS.
– Each logical processor has its own architecture state, which
includes general- purpose and machine-state registers.
– Each logical processor is responsible for its own interrupt
handling.
– SMT is a feature provided in hardware, not software.
• In essence, SMT enables a single physical CPU to appear as multiple
virtual CPUs, each capable of handling its own thread of execution.
This can lead to better utilization of the CPU's resources, increased
throughput, and improved performance, especially in multi-threaded
applications
85
 Thread Scheduling
• On OSs, it is kernel-level threads but not processes that are being
scheduled by the OS.
• User-level threads are managed by a thread library, and the kernel is
unaware of them.
• To run on a CPU, user-level threads must be mapped to an associated
kernel- level thread.

86
 • Contention Scope
– Two approaches:
• Process-Contention scope
• On systems implementing the many-to-one and many-to-many
models, the thread library schedules user-level threads to run on an
available LWP (Light-Weight Process).
• Competition for the CPU takes place among threads belonging to the
same process.
• System-Contention scope
– Scheduling threads using only System Contention Scope (SCS) involves
the operating system's kernel managing which threads get CPU time.
– In SCS, all threads in the system compete for CPU resources, and the
kernel decides which thread to run next.
– Operating systems like Windows, Linux, and Solaris use SCS for thread
87 scheduling
 • Systems using the one-to-one model, such as Windows, Linux,
and Solaris, schedule threads using only SCS.
• PCS is done according to priority— the scheduler selects the
runnable thread with the highest priority to run.
• User-level thread priorities are set by the programmer and are
not adjusted by the thread library, although some thread
libraries may allow the programmer to change the priority of a
thread.
• It is important to note that PCS will typically preempt the
thread currently running in favor of a higher-priority thread

88
 Pthread Scheduling
• The POSIX Pthread API that allows specifying PCS or SCS during
thread creation. Pthreads identifies the following contention scope
values:

– PTHREAD _SCOPE _PROCESS schedules threads using PCS

scheduling.
– PTHREAD_ SCOPE _SYSTEM schedules threads using SCS
scheduling.

89