Operating Systems R20 Unit 2.pptx

OPERATING SYSTEMS
PRUDHVI KIRAN P
Assistant Professor, CSE - IoT Dept.
R. V. R. & J. C. College of Engineering
UNIT 2

Operating Systems are an essential part of any
computer system. Similarly, a course on operating systems is an essential
part of any computer science education. This field is undergoing rapid
changes and advancements, as computers are now prevalent in virtually
every arena of day-to-day life. Yet the fundamental concepts remain
fairly clear and same till now, and it is on these that we discuss in this
course.

UNIT - 2 [ 12 Periods ]
Threads and Concurrency: Overview, Multicore Programming, Multithreading Models, Implicit
Threading, Threading Issues.
CPU Scheduling: Basic Concepts, Scheduling Criteria, Scheduling Algorithms, Thread Scheduling,
Multiple-Processor Scheduling, Real-Time CPU Scheduling.
Synchronization: Background, The Critical-Section Problem, Peterson solution, Hardware support
for Synchronization, Mutex Locks, Semaphores, Monitors, Classic Problems of Synchronization.
SUBJECT CODE - CD/CM/CO/CS/IT (R 20)
DETAILS - IoT IV SEM - MARCH 2023
FACULTY DETAILS - PRUDHVI KIRAN P, Asst. Prof., CSE (IoT), RVR&JC College of Engineering

QUESTION BANK - UNIT 2 [Assignment Questions - 4,6,15]
1. What is a thread? What are the common and unique aspects of the thread? Draw the block
diagram representation of Single Threaded and Multi-Threaded Process.
2. Draw and explain the working architecture of Multicore Programming Model.
3. Draw and explain the various multithreading models.
4. Define Implicit Threading and what are the various ways of implementation of Implicit
Threading.
5. Explain CPU Scheduling. Discuss the various factors to be considered while scheduling the
processes?
6. Explain FCFS and RR Scheduling Algorithms with practical example.
7. Explain non-pre-emptive and pre-emptive approach of SJF Scheduling Algorithms with practical
examples.
8. Discuss in detail about Process Affinity in association with NUMA and define how Load
Balancing affects the Process Affinity.
9. What is RTOS? Explain in detail about latency in RTOS with visual representation.
10. Describe the functionality of Rate-Monotonic Scheduling Algorithm, with practical example.
11. Describe the functionality of Earliest Deadline First Scheduling Algorithm, with practical
example.

END
12. what is synchronization and why it is important in OS? Explain the race condition with general
example.
13. Explain critical section in detail, with block diagram. Discuss about critical section problem and
requirements to be satisfied to avoid it.
14. Discuss Peterson solution for critical section problem with practical example.
15. Discuss about various methods that come under hardware support for synchronization problem
in operating system.
16. How semaphores and monitors achieve the proper synchronization between processes and
what is the difference between them.
17. Discuss about mutex locks in detail.
18. Discuss any two classic problems of synchronization? Explain them with relevant block
diagrams.

2.1.1 Threads and Concurrency: Overview
 A process is an instance of a program that is being executed. When we run a program, it does
not execute directly. It takes some time to follow all the steps required to execute the program,
and following these execution steps is known as a process.
 A thread is the subset of a process, i.e. a subprocess or an execution unit within a process.
Thread is also known as the lightweight process. A process can have more than one thread, and
these threads are managed independently by the scheduler. All the threads within one process
are interrelated to each other. Threads have some common information, such as data
segment, code segment, files, etc., that is shared to their peer threads. But contains its own
registers, stack, and counter.
 When a process starts, OS assigns the memory and resources to it. Each thread within a
process shares the memory and resources of that process only.
 Threads are mainly used to improve the processing of an application. In a scenario where
multiple threads related to a process are running, In reality, only a single thread is executed at
a time, but due to fast context switching between threads gives an illusion that threads are
running parallelly.
Working of Thread

 If only a single thread executes in a process, it is known as a single-threaded process and if
multiple threads execute simultaneously, then it is known as multi-threaded process or
multithreading.
SINGLE-THREADED PROCESS MULTI-THREADED PROCESS

This register contains the address of the next instruction to be executed by the currently executing
thread.
3. Register Set
Registers are a type of computer memory used to quickly accept, store, and transfer data and
instructions that are being used immediately by the CPU during execution of thread.
4. Stack space
If you have multiple threads, each one needs a stack, since they are all executing at the same time. It
allows multiple threads to share one core by pre-empting the execution of a thread, and starting
another thread. This includes PUSH and POP of threads from stack space.
A thread has the following four components:
1. Thread ID
2. Program Counter
3. Register Set
4. Stack space
1. Thread ID
2. Program Counter
Unique ID used by the operating system to identify thread in a process.

Multithreaded Server Architecture
 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. If the web
server ran as a traditional single-threaded process, it would be able to service only one client at
a time, and a client might have to wait a very long time for its request to be serviced.
 One solution is to have the server run as a single process that accepts requests. When the server
receives a request, it creates a separate process to service that request. In fact, this process-
creation method was in common use before threads became popular. Process creation is time
consuming and resource intensive, however. If the new process will perform the same tasks as
the existing process, why incur all that overhead? 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. When a request is made, rather than creating another process, the server
creates a new thread to service the request and resume listening for additional requests.
Operations in Multithreaded Server Architecture
1. Request (made by client to server)
2. Server create new thread to service the request
3. Server resume listening for additional client requests

Multithreaded Server Architecture

The benefits of multithreaded programming can be broken down into four major categories:
 Responsiveness
• Multithreading an interactive application as it allows a program to continue running even if part
of it is blocked or is performing a lengthy operation, thereby increasing responsiveness to the
user. Blocked or lengthy operation is handled by one thread and other tasks of program still runs
as it is handled by other threads.
• 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.
 Resource sharing
• Unlike processes, 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.
 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.
 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. Opening a new browser (say Chrome, etc) is
an example of creating a process. At this
point, a new process will start to execute. On
the contrary, opening multiple tabs in the
browser is an example of creating the thread.
B. An application that creates photo thumbnails
from a collection of images may use a
separate thread to generate a thumbnail from
each separate image.
C. A web browser might have one thread display
images or text while another thread retrieves
data from the network.
D. 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.
Understanding Threads with Daily usage scenarios

Communication between processes is slower. Communication between threads is faster.
Context Switching in processes is slower. Context switching in threads is faster.
Processes are independent of each other.
Threads, on the other hand, are interdependent.
(i.e. they can read, write or change another
thread’s data)
If one process is blocked then it will not affect the
execution of other processes
If a user-level thread is blocked, then all other
user-level threads are blocked.
Example: Opening two different browsers. Example: Opening two tabs in the same browser.
Understanding Thread and Process Comparatively
PROCESS THREAD
Processes use more resources and hence they
are termed as heavyweight processes.
Threads share resources and hence they are
termed as lightweight processes.
Creation and termination times of processes are
slower.
Creation and termination times of threads are
faster compared to processes.
Processes have their own code and data/file.
Threads share code and data/file within a
process.

 Earlier in the history of computer design, in response to the need for more computing
performance, single-CPU systems evolved into multi-CPU systems. A later, yet similar, trend in
system design is to place multiple computing cores on a single processing chip where each core
appears as a separate CPU to the operating system. We refer to such systems as multicore, and
multithreaded programming provides a mechanism for more efficient use of these multiple
computing cores and improved concurrency.
 Consider 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 some threads can run in parallel, because the
system can assign a separate thread to each core.
SINGLE CORE SYSTEM MULTI CORE SYSTEM
2.1.2 Multicore Programming

Both programming models execute programs at the same time, though the main difference
between the two is that parallel processing refers to running more than 1 program
simultaneously, usually with different computer systems (processors) communicating with each
other. These might be multiple CPUs or multiple threads on one core. On the other hand, multicore
processing means the execution of a programs on multiple cores of a single CPU.
Notice the distinction between concurrency (Multicore Programming) and parallelism (Parallel
Programming)
1. Energy Efficiency
2. True Concurrency
3. Performance
4. Isolation
5. Reliability and Robustness
6. Less Hardware Costs
7. Improved Maintainability
Multicore processing is considered by everyone because it offers advantages in the following seven
areas:

Task parallelism involves distributing not data
but tasks (threads) across multiple computing
cores. Each thread is performing a unique
operation. Different threads may be operating
on the same data, or they may be operating on
different data.
A. Data Parallelism B. Task Parallelism
Data parallelism focuses on distributing subsets
of the same data across multiple computing
cores and performing the same operation on
each core.
A. Data Parallelism
B. Task Parallelism
Two types of Parallelism is seen in Multicore Programming

1. Identifying Tasks
Multicore Programming Challenges
 The trend toward multicore systems continues to place pressure on system designers and
application programmers to make better use of the multiple computing cores.
 Designers of operating systems must write scheduling algorithms that use multiple processing
cores to allow the parallel execution and for application programmers, the challenge is to
modify existing programs as well as design new programs that are compatible with multicore
executing environment. Below five areas present challenges in programming for multicore
systems;
1. Identifying Tasks
2. Balance
3. Data Splitting
4. Data Dependency
5. Testing and Debugging
This involves examining applications to find areas that can be divided into separate, concurrent
tasks. Ideally, such considerable tasks are independent of one another and thus can run in parallel
on individual cores.
2. Balance
While identifying tasks that can run in parallel, programmers must also ensure that the tasks
perform equal work of equal value on all available cores.

In some instances, a certain task may not contribute as much value to the overall process as other
tasks. Using a separate execution core to run that task may not be worth the cost.
Just as applications are divided into separate tasks, the data accessed and manipulated by the tasks
must be divided to run on separate cores.
4. Data Dependency
When one task depends on data from another, programmers must ensure that the execution of the
tasks is synchronized manner to accommodate the fail proof data dependency.
5. Testing and Debugging
When a program is running in parallel on multiple cores, many different execution paths are
possible. Testing and debugging such concurrent programs is more difficult than testing and
debugging single-threaded applications.
3. Data Splitting
Intel Core i3 - 2 Cores
No. of Cores in Intel Multicore Processors

2.1.3 Multithreading Models
 Multithreading divides the task of application into separate individual threads. The same
process or tasks in multithreading environment can be done by several threads or it can be said
that more than one thread is used for performing the tasks in multithreading.
Example Scenario
For instance, in the banking system, many users perform a day-to-day activities using bank servers
like transfers, payments, deposits, opening a new account, etc., instantly without having to wait
for another user to finish.
 The threads in this scenario are divided into user-level and kernel-level threads. The 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. Both user
level threads and kernel level threads coordinate with each other to make a process
successful. Ultimately, a relationship must exist between user threads and kernel threads. We
look at three common ways of establishing such a relationship;
1. The Many -to- One Model 2. The One -to- One Model 3. The Many -to- Many Model

1. The Many -to- One Model
 The many-to-one model maps many user-level
threads to one kernel thread.
 In this model, multiple threads cannot run in parallel
as only one thread can access the kernel at a time.
 Thread management is done by the thread library in
user space, so it is efficient. But on the other hand,
the entire process will block if any thread makes a
blocking system call, as other threads are also
connected to the same kernel thread which receives
the blocking system call sent by on of the user
threads.
 Green threads - a thread library available for Solaris
systems and adopted in early versions of Java used
the many-to-one model. At present day, very few
systems continue to use the model because of its
inability to take advantage of multiple processing.

 The one-to-one model maps each user thread to a different 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.
 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.
 Linux, along with the family of Windows operating systems, implement this one-to-one model of
multi threading.
2. The One -to- One Model

 The many-to-many model multiplexes many user-
level threads to a smaller or equal number of kernel
threads.
 The many to many does not have the shortcomings
of the one to one model or the many to one model;
Whereas the many-to-one model allows the
developer to create as many user threads as she
wishes, but kernel can schedule only one thread at a
time. And one -to- one model allows greater
concurrency, but the developer has to be careful not
to create too many threads within an application,
which effects the efficiency.
 There can be as many user threads as required and
their corresponding kernel threads can run in
parallel. Also, when a thread performs a blocking
system call, the kernel can schedule another thread
for execution.
 Microsoft Win32 OS supports the many-to-many
model.
3. The Many -to- Many Model

 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 (any one) to be
bound to a kernel thread (any one). This variation is sometimes referred to as the two-level
model.
 The Solaris operating system supported the two-level model in versions older than Solaris 9.
However, beginning with Solaris 9, this system uses the one-to-one model.
Two-level model (Variant of Many -to- Many Model)

2.1.4 Implicit Threading
 With the continued growth of multicore processing, applications containing hundreds or even
thousands of threads are seen today. Designing such applications is not an easy task.
Programmers must address not only the challenges of multi core programming model but
additional difficulties as well, which are related to thread scheduling.
 One way to address these difficulties and better support the design of multithreaded
applications is to transfer the creation and management of threading from application
developers to compilers and run-time libraries. This, termed implicit threading, is a popular
trend today.
 It’s basically a question of who’s going to do the parallelism in your code. For example, if you
decompose your work into tasks and coordinate between them then it’s explicit parallelism
because you are the one doing it. On the other hand, if the system (the libraries, compiler, OS) is
doing it for you then it’s implicit parallelism.
 A programmer that writes implicitly parallel code does not need to worry about task division
or process communication, focusing instead on the problem that his or her program is
intended to solve. Implicit parallelism generally facilitates the design of parallel programs and
therefore results in a substantial improvement of programmer productivity.

There are three alternative approaches for designing multithreaded programs that can take
advantage of multicore processors through implicit threading.
1. Thread Pools
 In multithreaded web server, whenever the server receives a request, it creates a separate
thread to service the request.
 The first issue concerns the amount of time required to create the thread, together with the fact
that the thread will be discarded once it has completed its work. The second issue is more
troublesome. If we allow all concurrent requests to be serviced in a new thread, we have not
placed a bound on the number of threads concurrently active in the system. Unlimited threads
could exhaust system resources, such as CPU time or memory. One solution to address these
problems is to use a thread pool.
 The general idea behind a thread pool is to create a number of threads at process startup and
place them into a pool, where they sit and wait for work. When a server receives a request, it
awakens a thread from this pool - if one is available - and passes it the request for service. Once
the thread completes its service, it returns to the pool and awaits more work. If the pool contains
no available thread, the server waits until one becomes free.
Thread pools offer these benefits:
A. Servicing a request with an existing thread is faster than waiting to create a thread.

B. A thread pool limits the number of threads that exist at any one point. This is particularly
important on systems that cannot support a large number of concurrent threads.
C. Separating the task to be performed from the mechanics of creating the task allows us to use
different strategies for running the task. For example, the task could be scheduled to execute after a
time delay or to execute periodically.
The number of threads in the pool can be set heuristically based on factors such as the number of
CPUs in the system, the amount of physical memory, and the expected number of concurrent client
requests. More sophisticated thread-pool architectures can dynamically adjust the number of
threads in the pool according to usage patterns. Such architectures provide the further benefit of
having a smaller pool - thereby consuming less memory - when the load on the system is low. One
such architecture is Apple’s Grand Central Dispatch.
2. OpenMP
OpenMP is a set of compiler directives as well as an API for programs written in C, C++, or FORTRAN
that provides support for parallel programming in shared-memory environments. OpenMP identifies
parallel regions as blocks of code that may run in parallel. Application developers insert compiler
directives into their code at parallel regions, and these directives instruct the OpenMP run-time
library to execute the region in parallel.

3. Grand Central Dispatch
 Grand Central Dispatch, is a technology developed by Apple Inc. to optimize application support
for multi-core processors and other symmetric multiprocessing requirements in devices runs on
Apple’s Mac OS X and iOS operating systems. It is an implementation of thread parallelism based
on the thread pool pattern.
 Grand Central Dispatch (GCD) a technology developed by Apple Inc. for Apple’s Mac OS X and
iOS operating systems, helps to optimize application support for multi-core processors and other
symmetric multiprocessing requirements.
 Working of GCD is a combination of placing extensions to the code, an API and a run-time library
that allows application developers to identify sections of code to run in parallel.
 GCD identifies extensions to the C and C++ languages known as blocks. A block is simply a self-
contained unit of work. It is specified by a symbol called caret ˆ inserted in front of a pair of
braces { }. A simple example of a block is ˆ{ printf("I am a block"); }
 GCD schedules blocks for run-time execution by placing them on a dispatch queue. When it
removes a block from a queue, it assigns the block to an available thread from the thread pool it
manages.
 GCD identifies two types of dispatch queues:
I. Serial - FIFO plus Running block must complete execution before another block is dispatched.

Other Approaches
Thread pools, OpenMP, and Grand Central Dispatch are just a few of many emerging technologies for
managing multithreaded applications. Other commercial approaches include parallel and concurrent
libraries, such as Intel’s Threading Building Blocks (TBB) and several products from Microsoft. The
Java language and API have seen significant movement toward supporting concurrent programming
as well. A notable example is the java.util.concurrent package, which supports implicit thread
creation and management
II. Concurrent - FIFO plus several blocks may be dispatched at a time, and can be executed in
parallel.

2.1.5 Threading Issues
Some of the issues to be consider in designing multithreaded programs;
1. The fork() and exec() System Calls
 In processes concept, the fork() system call is used to create a separate, duplicate process. But in
a multithreaded program. If one thread in a program calls fork(), does the new process
duplicate all threads, or is the new process single-threaded? Some UNIX systems have chosen
to have two versions of fork(), one that duplicates all threads and another that duplicates only
the thread that invoked the fork() system call. Which of the two versions of fork() to use
depends on the application.
 The exec() system call typically works in the same way as described in processes concept. That
is, if a thread invokes the exec() system call, the program specified in the parameter to exec()
will replace the entire ongoing process, including all threads.
• If exec() is called immediately after fork(), then duplicating all threads reg. fork() is
unnecessary, as the program specified in the parameters to exec() will replace the process. If,
however, the separate process does not call exec() after forking, the separate process should
duplicate all threads.
Special Case

2. Signal Handling
A signal is used in UNIX systems to notify a process that a particular event has occurred. A signal
may be received either synchronously or asynchronously. depending on the source of and the
reason for the event being signalled.
 Synchronous signals are delivered to the same process that performed the operation that
caused the signal. Operations like, illegal memory access and division by 0.
 In case of Asynchronous signals, when a signal is generated by an event external to a running
process, that process receives the signal asynchronously. Operations like terminating a process
with specific keystrokes, having a timer expire, triggers asynchronous signals.
All signals, whether synchronous or asynchronous, follow the same pattern:
A. 1. A signal is generated by the occurrence of a particular event.
B. 2. The signal is delivered to a process.
C. 3. Once delivered, the signal must be handled.
A signal may be handled by one of two possible handlers:
1. A default signal handler
2. A user-defined signal handle

Every signal has a default signal handler that the kernel runs when handling that signal. This default
action can be overridden by a user-defined signal handler that is called to handle the signal.
 Handling signals in single-threaded programs is straightforward: signals are always delivered to
a process. However, delivering signals is more complicated in multithreaded programs, where a
process may have several threads. In general, the following options exist for this situation;
1. Deliver the signal to the thread to which the signal applies.
2. Deliver the signal to every thread in the process.
3. Deliver the signal to certain threads in the process.
4. Assign a specific thread to receive all signals for the process.
Choosing the method from above four options for delivering a signal depends on the type of signal
generated;
 Synchronous signals need to be delivered to the thread causing the signal and not to other
threads in the process.
 However, the situation with asynchronous signals is not as clear. Some asynchronous signals
such as a signal that terminates a process (Closing a Browser in which 10 tabs are opened)
should be sent to all threads.

3. Thread Cancellation
 Thread cancellation involves terminating a thread before it has completed. For example, if
multiple threads are concurrently searching through a database and one thread returns the
result, the remaining threads might be cancelled.
 Another situation might occur when a user presses a button on a web browser that stops a web
page from loading any further. Often, a web page loads using several threads - each image is
loaded in a separate thread. When a user presses the stop button on the browser, all threads
loading the page are cancelled.
A thread that is to be cancelled is often referred to as the target thread. Cancellation of a target
thread may occur in two different scenarios:
 Asynchronous cancellation - Immediately terminates the target thread. This is a kind of
asynchronous signal scenario.
 Deferred cancellation. The target thread periodically checks whether it should terminate,
allowing it an opportunity to terminate itself in an orderly fashion.
 The difficulty with cancellation occurs in situations where resources have been allocated to a
cancelled thread or where a thread is cancelled while in the midst of updating data it is sharing
with other threads. This becomes especially troublesome with asynchronous cancellation.

4. Thread Local Storage
In general threads belonging to a process, share the data of that process. Indeed, this data sharing
provides one of the benefits of multithreaded programming. However, in some circumstances, each
thread might need its own copy of certain data. We will call such data thread-local storage (or TLS).
For example, in a transaction processing system, we might service each transaction in a separate
thread. Furthermore, each transaction might be assigned a unique identifier. To associate each
thread with its unique identifier, we could use thread-local storage.
 Static and global data are shared across all the threads. If you modified a global/static variable it
is visible to all the threads. Unlike global/shared variable if you create a variable in TLS, every
thread has its own copy of the variable, i.e. changes to the variable is local to the thread.
5. Scheduler Activations
One scheme for communication between the user-thread library and the kernel is known as
scheduler activation.
 A final issue to be considered with multithreaded programs concerns communication between
the kernel and the user-thread library, which may be required by the many-to-many and two-
level multi-threaded models.
 Good communication and coordination allows the number of kernel threads to be dynamically
adjusted to help ensure the best performance.

2.2.1 CPU Scheduling - Basic Concepts
 In the Uniprogrammming systems like MS DOS, when a process waits for any I/O operation to
be done, the CPU remains idol. This is an overhead since it wastes the time and causes the
problem of starvation. However, In Multiprogramming systems, the CPU doesn't remain idle
during the waiting time of the Process and it starts executing other processes. The Operating
system does this by scheduling of processes on the CPU to have the maximum utilization of it
and this procedure is called CPU scheduling. The Operating System uses various scheduling
algorithms to schedule the processes.
Uniprogramming refers to computer operating systems that use one thread at a time, i.e. browser,
calculator or word processor runs one after another in their turn. Multiprogramming uses more
than one thread at a time and involves multicore processors.
 This is a task of the short term scheduler to schedule the CPU for the number of processes
present in the Job Pool/Ready State. Whenever the running process requests some IO
operation then the short term scheduler saves the current context of the process (also called
PCB) and changes its state from running to waiting. During the time, process is in waiting state;
the Short term scheduler picks another process from the ready queue and assigns the CPU to
this process. This procedure is called context switching.

 Process execution consists of a cycle of CPU execution and I/O wait. The state of process under
execution is called CPU burst and the state of process under I/O request & its handling is called
I/O burst. 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. Eventually, the final CPU burst ends with a system request to terminate
execution. This refers to CPU-I/O Burst Cycle.
CPU Burst and I.O Burst Cycle
CPU Scheduler
 The scheduler selects a process from the processes in memory that are ready to execute and
allocates the CPU to that process. The selection process is carried out by the short-term
scheduler, which is important than other two available CPU schedulers (long-term and medium-
term).
 Note that the ready queue is not necessarily a first-in, first-out (FIFO) queue. As we consider the
various scheduling algorithms, a ready queue can be implemented as a FIFO queue, a 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.

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.
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 requested I/O operation.
4. When a process terminates.
 When scheduling takes place only under circumstances 1 and 4, we say that the scheduling
scheme is non pre-emptive or cooperative in which executing process gives up the CPU
voluntarily. Otherwise, it is pre-emptive in which OS may allocate the resources to a process for
a fixed amount of time or the OS may give priority to other processes and replace the current
executing process higher priority process.
 Unfortunately, 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.

Dispatcher
 A dispatcher is a special program that comes into play after the scheduler. When the short term
scheduler selects from the ready queue, the Dispatcher performs the task of allocating the
selected process to the CPU. A running process goes to the waiting state for IO operation etc.,
and then the CPU is allocated to some other process. This switching of CPU from one process to
the other is called context switching.
 A dispatcher performs context switching and various tasks necessary for the process to execute
and transfer CPU control to that process. When dispatching, the process changes from the ready
state to the running state.
 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.

2.2.2 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 various properties of the algorithms.
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).
Throughput
If the CPU is busy executing processes, then work is being done. One measure of this 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.
Turnaround time
From the point of view of a particular process, the important criterion is 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/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
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.
It is desirable to maximize CPU utilization and throughput and to minimize turnaround time, waiting
time, and response time.

2.2.3 Scheduling Algorithms
 CPU scheduling deals with the problem of deciding which of the processes in the ready queue
is to be allocated the CPU based on particular scheduling algorithms. These algorithms are
either Non-Pre-emptive or Pre-emptive.
 Non-Pre-emptive algorithms are designed so that once a process enters the running state, it
cannot be pre-empted until it completes its allotted time.
 Pre-emptive 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. Sometimes it is
important to run a task with a higher priority before another lower priority task, even if the
lower priority task is still running.
There are various algorithms which are used by the Operating System to schedule the processes on
the processor in an efficient way:
1. First Come First Serve (FCFS) Scheduling Algorithm
2. Shortest Job First (SJF) Scheduling Algorithm
3. Priority Scheduling Algorithm
4. Round - Robin (RR) Scheduling Algorithm
5. Multilevel - Queue Scheduling Algorithm
6. Multilevel - Feedback Queue Scheduling Algorithm

1. First Come First Serve (FCFS) Scheduling Algorithm
 By far the simplest CPU-scheduling algorithm is the first-come, first-served (FCFS) scheduling
algorithm. With this scheme, 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. FCFS scheduling
algorithm is non pre-emptive. On the negative side, the average waiting time under the FCFS
policy is often quite 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
CASE 1 - 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:

From above Gantt chart, 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.
CASE 2 - If the processes arrive in the order P2, P3, P1, and are served in FCFS order, we get the
result shown in the following Gantt chart;
From above Gantt chart, the waiting time is 0 milliseconds for process P2, 3 milliseconds for
process P3, and 6 milliseconds for process P1. Thus, the average waiting time is (0 + 3 + 6)/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.
Once the CPU has been allocated to a process, that process keeps the CPU until it releases the
CPU, either by terminating or by requesting I/O. The FCFS algorithm is thus particularly
troublesome for time-sharing systems, where it is important that each user get a share of the
CPU at regular intervals. It would be disastrous to allow one process to keep the CPU for an
extended period.

FCFS - Convoy Effect
Assume we have one CPU-bound process and many I/O-bound processes. As the processes flow
around the system, the following scenario may result; The CPU-bound process will get and hold the
CPU. During this time, all the other processes will finish their I/O and will move into the ready queue,
waiting for the CPU. While the processes wait in the ready queue, the I/O devices are idle. Eventually,
the CPU-bound process finishes its CPU burst and moves to an I/O device. All the I/O-bound
processes, which have short CPU bursts, execute quickly and move back to the I/O queues. At this
point, the CPU sits idle. The CPU-bound process will then move back to the ready queue and be
allocated the CPU. Again, all the I/O processes end up waiting in the ready queue until the CPU-
bound process is done. 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.
CONVOY EFFECT - VISUALIZING STARVATION

Advantages & Disadvantages of FCFS scheduling
Advantages
 Simple to implement
 Easy to Understand
Disadvantages
 Convoy effect
 Low CPU utilization (Consecutive waiting among I/o Burst, CPU Burst)
 Increased average waiting time.

2. Shortest Job First (SJF) Scheduling Algorithm
 A different approach to CPU scheduling is the shortest-job-first(SJF) scheduling algorithm. This
algorithm associates with each process the length of the process’s next CPU burst.
 When the CPU is available, it is assigned to the process that has the smallest next CPU burst. If
the next CPU bursts of two processes are the same, FCFS scheduling is used to break the tie.
 Note that a more appropriate term for this scheduling method would be the shortest-next CPU
burst algorithm, because scheduling depends on the length of the next CPU burst of a process,
rather than its total length.
As an example of SJF scheduling, consider the following set of processes, with the length of the
CPU burst given in milliseconds
PROCESS BURST TIME
P1 6
P2 8
P3 7
P4 3
Using Shortest Job First scheduling algorithm, 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. By comparison, if we were using the FCFS scheduling scheme, the average waiting
time would be 10.25 milliseconds.
 SJF can be pre-emptive and non-pre-emptive. In non-preemptive scheduling, once the CPU
cycle is allocated to process, the process holds it till it reaches a waiting state or terminated; that
is seen in the above mentioned scenario. Here process table is constructed before starting the
execution.
 In Preemptive SJF Scheduling, jobs starts execution as they arrive and then followed by process
with shortest burst time process executes first. I.e. If a process with even a shorter burst time
than the ongoing process arrives, the first arrived process is removed or preempted from
execution, and the shorter job came now is allocated CPU cycle and started to get executed,
and this continues, till all processes done with execution. Here process table is not initially
available, as the processes are arriving dynamically.
SJF - Pre-emptive Model (Shortest Remaining Time First Scheduling Algorithm)

PROCESS
BURST
TIME
Arrival
Time
P1 8 0
P2 4 1
P3 9 2
P4 5 3
If the processes arrive at the ready queue at the times shown and executed based on priority
(shortest burst time), then the resulting pre-emptive SJF schedule is as depicted in the following
Gantt chart;
Detailed Process
Initially, P1 loaded at 0th second, as it arrived first; after getting executed for 1 second, P2 arrived as
1 second is it’s arrival time. At this point, the burst time of P1 is 7 (as 1 second is completed) and the
burst time of newly arrived P2 is 4. Both of these burst times are compared and the shortest one is
selected to pre-empt the longest. I.e. P2 pre-empts P1, consider P1 is sent to waiting Queue.
P1
0 1 2 3 4
TIME
P2 STARTED

P1
0 1 2 3 4 5 6
TIME
P3 ARRIVED
P4 ARRIVED
PRE-EMPTED
PROCESS
REMAINING
BURST TIME
P1 7
P3 9
P4 5
P2
P1
0 1 5 10
TIME
PRE-EMPTED
PROCESS
REMAINING
BURST TIME
P1 7
P3 9
P2 P4
P1
0 1 5 10 17
TIME
PRE-EMPTED
PROCESS
REMAINING
BURST TIME
P3 9
P2 P4 P1
P1
0 1 5 10 17 26
TIME
P2 P4 P1 P3
P3, P4 Arrived as per their arrival times
but sent to Pre-Empted Process Queue,
as their burst time is higher than P2,
later they are executed based on SJF

P1
0 1 5 10 17 26
TIME
P2 P4 P1 P3
From the above Gantt chart, the average waiting time for this example is [(10 − 1 − 0) + (1 − 1) + (17
− 2) + (5 − 3)]/4 = 26/4 = 6.5 milliseconds. Non-preemptive SJF scheduling would result in an average
waiting time of 7.75 milliseconds. Note that, in this algorithm, while calculating the average waiting
time the arrival time will be subtracted from the actual waiting time observed; in above formula,
the sums order is P1, P2, P3, P4. Only for P1 instead of writing 10-0, we write 10-1-0, that 1 in the
middle represents 1 second of P1 is already processed and the followed 0 represents the given
arrival time of P1.
Advantages & Disadvantages of SJF scheduling
Advantages
 Shortest jobs are favored.
 Gives the minimum average waiting time for a given set of processes.
Disadvantages
 Used effectively and simply only by long term schedulers.

3. Priority Scheduling Algorithm
 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 next CPU burst. The larger the CPU burst,
the lower the priority, and vice versa.
 Note that we discuss scheduling in 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. In our discussion, we assume that low numbers represent high priority.
As an example, consider the following set of processes, assumed to
have arrived at time 0 in the order P1, P2, P3, P4, P5, with the length of
the CPU burst given in milliseconds
PROCESS
BURST
TIME
PRIORI
TY
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 below Gantt chart;

Given processes are on the Gantt chart, as per their priority, with out bothering about the CPU burst
times. The average waiting time observed here is 8.2 milliseconds, i.e. sum of waiting times of
P1,P2,P3,P4,P5 divided by 5, which is (6+0+16+18+1)/5.
Priority Factors
 Priorities can be defined either internally or externally. Internal priorities use some measurable
quantity or quantities to compute the priority of a process, these priorities are related to CPU. 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 can be either Pre-emptive or Non-Pre-emptive:
When a process arrives at the ready queue, its priority is compared with the priority of the
currently running process. A Pre-emptive priority scheduling algorithm will Pre-empt the CPU if
the priority of the newly arrived process is higher than the priority of the currently running
process. This process is same as we done in the Pre-emptive model of SJF Scheduling Algorithm.

Starving - Major Problem with Priority Scheduling
A major problem with priority scheduling algorithms is indefinite blocking, or starvation. A process
that is ready to run but waiting for the CPU can be considered blocked. 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
(Considering a working day scenario - 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.
Aging - Solution to Starving
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 increase the priority of a waiting process by 1
every 15 minutes. Eventually, even a process with an initial priority of 127 would have the highest
priority in the system and would be executed.
Advantages & Disadvantages of Priority scheduling
Advantages
 Easy to use scheduling method.
 High priority does not need to wait for long which saves time.

Disadvantages
 Starvation of low priority processes.
 Another problem is deciding which process gets which priority level assigned to it.
 If the system eventually crashes, all low priority processes get lost.
Rumour 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.

4. Round - Robin (RR) Scheduling Algorithm
 The round-robin (RR) scheduling algorithm is designed especially for timesharing systems. It is
similar to FCFS scheduling, but Pre-emption 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, 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 to running.
 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.

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 Pre-empted 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. The Gantt Chart of resulting RR schedule is as follows:
P1
0 4
TIME
PROCESS
BURST
TIME
P2 3
P3 3
P1 20

P1
0 4 7 8
TIME
PROCESS
BURST
TIME
P3 3
P1 20
P2
Even though given time
quantum is 4, P2 CPU
burst in only 3 Seconds, so
it voluntarily leaves hold
on CPU
P1
0 4 7 8 10
TIME
PROCESS
BURST
TIME
P1 20
P2
Even though given time
quantum is 4, P3 CPU
burst in only 3 Seconds, so
it voluntarily leaves hold
on CPU
P3

P1
0 4 7 10 14
TIME
PROCESS
BURST
TIME
P1 16
P2 P3 P1
P1
0 4 7 10 14 18
TIME
PROCESS
BURST
TIME
P1 12
P2 P3 P1 P1
P1
0 4 7 10 14 18 22
TIME
PROCESS
BURST
TIME
P1 8
P2 P3 P1 P1 P1
P1
0 4 7 10 14 18 22 26
TIME
PROCESS
BURST
TIME
P1 4
P2 P3 P1 P1 P1 P1
P1
0 4 7 10 14 18 22 26 30
TIME
P2 P3 P1 P1 P1 P1 P1 PROCESS
BURST
TIME

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.
 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; thus the RR scheduling
algorithm is thus preemptive.
 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.
Advantages & Disadvantages of RR scheduling
Advantages
 Every process gets an equal share of the CPU.
 RR is cyclic in nature, so there is no starvation.

Disadvantages
 Setting the quantum too short increases the overhead and lowers the CPU efficiency, but setting it
too long may cause a poor response to short processes.
 The average waiting time under the RR policy is often long.
 If time quantum is very high then RR degrades to FCFS.

5. Multilevel - Queue Scheduling Algorithm
 Another class of scheduling algorithms has been created for situations in which processes are
easily classified into different groups. For example, a common division is made between
foreground (interactive) processes and background (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.
 A multilevel queue scheduling algorithm
partitions the ready queue into several separate
queues as shown in figure. 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.
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.

 Each queue has absolute priority over lower-priority queues. No process in the batch queue, for
example, 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 pre-empted. So this scheduling model
is Pre-emptive scheduling model.
 Another possibility is to time-slice among the queues. Here, 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 example, 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.
Advantages & Disadvantages of Multilevel Queue scheduling
Advantages
 separate scheduling for various kinds of processes is possible; Like mentioned below:
• System Process - FCFS and Interactive Process - SJF
• Batch Process - RR and Student Process - PB
Disadvantages
 The lowest level process faces the starvation problem.

5. Multilevel - Feedback Queue Scheduling Algorithm
 Normally, when the multilevel queue scheduling algorithm is used, processes are permanently
assigned to a queue when they enter the system. If there are separate queues for foreground
and background processes, for example, processes do not move from one queue to the other,
since processes do not change their foreground or background nature.
 The multilevel feedback queue scheduling algorithm, in contrast, allows a process to move
between queues. The idea is to separate processes according to the characteristics of their CPU
bursts. If a process uses too much CPU time, it will be moved to tail of a lower-priority queue.
 This scheme leaves I/O-bound and interactive processes in the higher-priority queues. In addition,
a process that waits too long in a lower-priority queue may be moved to a higher-priority
queue. This form of aging prevents starvation.
For example, consider a multilevel feedback queue scheduler with three queues, numbered from 0,
1 & 2, as shown in figure.
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.

QUEUE 0
QUEUE 1
QUEUE 2
HIGH PRIORITY
LOW PRIORITY
A process entering the ready queue is put in 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 pre-empted and is put into queue 2. Processes in queue 2 are run on an FCFS basis but
are run only when queues 0 and 1 are empty. This scheduling algorithm gives highest priority to any
process with a CPU burst of 8 milliseconds or less.

In general, a multilevel feedback queue scheduler is defined by the following parameters:
 The number of queues.
 The scheduling algorithm for each queue.
 The method used to determine when to upgrade a process to a higher priority queue.
 The method used to determine when to demote a process to a lower priority queue.
 The method used to determine which queue a process will enter when that process needs service.
The definition of a multilevel feedback queue scheduler makes it the most general CPU-scheduling
algorithm. It can be configured to match a specific system under design. Unfortunately, it is also
the most complex algorithm, in terms of designing.
Advantages & Disadvantages of Multilevel Feedback Queue scheduling
Advantages
 Low scheduling overhead.
 Allows aging, thus no starvation.
Disadvantages
 It’s not flexible.
 Hard, As it requires means of selecting values for all the parameters to define the best scheduler.

2.2.4 Thread Scheduling
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. Ultimately a
relationship must exist between user threads and kernel threads. 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
ultimately be mapped to an associated kernel-level thread, although this mapping may be indirect
and may use a lightweight process (LWP).LWPs bridge the user level and the kernel level. Each
process contains one or more LWP, each of which runs one or more user threads.
Scheduling issues involving user-level and kernel-level threads;
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. This scheme is known as Process
Contention Scope (PCS).
 When thread library schedules user threads onto available LWPs, it doesn't mean that the
threads are actually running on a CPU. That would require the operating system to schedule the
kernel thread onto a physical CPU. To decide which kernel-level thread to schedule onto a CPU,
the kernel uses System - Contention Scope (SCS).

Competition for the CPU with SCS scheduling takes place among
all threads in the system. PCS is done according to priority; the
scheduler selects the runnable thread with the highest priority to
run. PCS will typically pre-empt the thread currently running in
favour of a higher-priority thread.

2.2.5 Multiple-Processor Scheduling
Our discussion thus far has focused on the problems of scheduling the CPU in a system with a single
processor. If multiple CPUs are available, load sharing becomes possible - but scheduling
problems become correspondingly more complex. We concentrate on systems in which the
processors are identical - homogeneous in terms of their functionality. We can then use any
available processor to run any process in the queue. Note, however, that even with homogeneous
multiprocessors, there are sometimes limitations on scheduling. Consider a system with an I/O
device attached to a private bus of one processor. Processes that wish to use that device must be
scheduled to run on that processor.
Approaches to CPU Scheduling in a Multiple-Processor System
Asymmetric Multiprocessing
 All scheduling decisions, I/O processing, and other system activities handled by a single
processor - the master server. The other processors execute only user code. This asymmetric
multiprocessing is simple because only one processor accesses the system data structures,
reducing the need for data sharing.
Symmetric Multiprocessing (SMP)
 Each processor is self-scheduling. All processes may be in a common ready queue, or each
processor may have its own private ready queues.

 Scheduling in ASM proceeds by having the scheduler for each processor examine the ready
queue and select a process to execute.
 When multiple processors trying to access and update a common data structure, the scheduler
must be programmed carefully. We must ensure that two separate processors do not choose
to schedule the same process. Virtually all modern operating systems support SMP, including
Windows, Linux, and Mac OS X. In the remainder of this section, we discuss issues concerning
SMP systems.
Processor Affinity
 Consider what happens to cache memory when a process has been running on a specific
processor. The data most recently accessed by the process populate the cache for the
processor. As a result, successive memory accesses by the process are often satisfied in cache
memory.
 Now consider what happens if the process migrates to another processor. The contents of
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 systems try to
avoid migration of processes from one processor to another and instead attempt to keep a
process running on the same processor. This is known as processor affinity; that is, a process
has an affinity for the processor on which it is currently running.

Process Affinity Types
1. When an operating system has a policy of attempting to keep a process running on the same
processor - but not guaranteeing that it will do so; then we have a situation known as SOFT
AFFINITY.
2. The operating system will attempt to keep a process on a single processor, but it is possible for
a process to migrate between processors; then we have a situation known as HARD AFFINITY.
Non-Uniform Memory Access (NUMA)
NUMA defines the main-memory
architecture of a system that can help
in handling processor affinity issues. In
NUMA, CPU has faster access to some
parts of main memory than to other
parts. Typically, this occurs in systems
containing combined CPU and memory
boards. The CPUs on a board can
access the memory on that board
faster than they can access memory on
other boards in the system.

If the Operating System’s CPU scheduler and Memory-Placement Algorithms work together, then a
process that is assigned affinity to a particular CPU can be allocated memory on the board where
that CPU resides.
Load Balancing
 On SMP systems, it is important to keep the workload balanced among all processors to fully
utilize the benefits of having more than one processor. Otherwise, one or more processors may
sit idle while other processors have high workloads. Load balancing attempts to keep the
workload evenly distributed across all processors in an SMP system. It is important to note that
load balancing is typically necessary only on systems where each processor has its own private
queue of eligible processes to execute. On systems with a common ready queue, load balancing
is often unnecessary, because once a processor becomes idle, it immediately extracts a runnable
process from the common ready queue. There are two general approaches to load balancing;
1. Push Migration
A specific task periodically checks the load on each processor and if it finds an imbalance, it evenly
distributes the load by pushing processes from overloaded to idle or less-busy processors.
2. Pull Migration
This occurs when an idle processor pulls a waiting task from a busy processor. Push and pull
migration are often implemented in parallel on load-balancing systems.

 Load balancing often counteracts the benefits of processor affinity, that is, the benefit of
keeping a process running on the same processor is that the process can take advantage of its
data being in that processor’s cache memory. Either pulling or pushing a process from one
processor to another removes the benefit of processor affinity.
 As is often the case in systems engineering, there is no absolute rule concerning what policy is
best. Thus, in some systems, an idle processor always pulls a process from a non-idle
processor. In other systems, processes are moved only if the imbalance exceeds certain
threshold.

2.2.6 Real-Time CPU Scheduling
 A real-time operating system (RTOS) is a special-purpose operating system used in computers
that has strict time constraints for any job to be performed. It is employed mostly in those
systems in which the results of the computations are used to influence a process while it is
executing.
 Whenever an event external to the computer occurs, it is communicated to the computer with
the help of some sensor used to monitor the event. The sensor produces the signal that is
interpreted by the operating system as an interrupt. On receiving an interrupt, the operating
system invokes a specific process or a set of processes to serve the interrupt.
 This process is completely uninterrupted unless a higher priority interrupt occurs during its
execution. Therefore, there must be a strict hierarchy of priority among the interrupts.
 Example Real Time Systems include; Command control Systems, Airline reservation systems,
Heart Pacemaker, Network Multimedia Systems, etc. Comparing RTOS with GPOS (General
Purpose Operating System); GPOS is used for desktop PC and laptop where as RTOS is only
applied to the embedded application.
In general, Real Time Systems can be;
A. Soft real-time systems
B. Hard real-time systems

Soft real-time systems provide no guarantee as to when a critical real-time process will be
scheduled. They guarantee only that the process will be given preference over noncritical
processes. Hard real-time systems have stricter requirements. A task must be serviced by its
deadline; service after the deadline has expired is the same as no service at all.
Several issues related to process scheduling in both soft and hard real-time operating systems
Minimizing Latency
Consider the event-driven nature of a real-time system. The system is typically waiting for an
event in real time to occur. Events may arise either in software as when a timer expires or in
hardware as when a remote-controlled vehicle detects that it is approaching an obstruction. When
an event occurs, the system must respond to and service it as quickly as possible. We refer to
event latency as the amount of time that elapses from when an event occurs to when it is
serviced.
Two types of latencies affect the performance of real-time systems:
A. Interrupt latency
B. Dispatch latency
Interrupt latency refers to the period of time from the arrival of an interrupt at the CPU to the
start of the routine that services the interrupt. The amount of time required for the scheduling
dispatcher to stop one process and start another is known as dispatch latency.

INTERRUPT LATENCY
Interrupt
Service
routine

DISPATCH LATENCY
Pre-emption &
Resource Releasing of
running process (low -
priority)

Usually, different events have different latency requirements. For example, the latency
requirement for an antilock brake system might be 3 to 5 milliseconds. That is, from the time a
wheel first detects that it is sliding, the system controlling the antilock brakes has 3 to 5
milliseconds to respond to and control the situation. Any response that takes longer might result in
the automobile’s veering out of control. In contrast, an embedded system controlling radar in an
airliner might tolerate a latency period of several seconds.
There are two types of tasks in real-time systems
1. Periodic tasks
2. Dynamic tasks
1. Periodic tasks
In periodic tasks, jobs are released at regular intervals. A periodic task is one that repeats itself after
a fixed time interval.
Consider the task T with period = 5 and execution time = 3. The job of this task is first released
(started) at 0ms then it executes for 3ms and then the next job is released at t = 5 which executes for
3ms and then the next job is released at t = 10 which executes for 3ms.
TIME
T(1)
T T T
Idea state, no
task will run

2. Dynamic tasks
It is a sequential program that is invoked by the occurrence of an event. An event may be
generated by the processes external to the system or by processes internal to the system. These are
aperiodic tasks in which jobs are released at arbitrary time intervals i.e. randomly.

Rate-Monotonic Scheduling Algorithm - For RTOS
 The rate-monotonic scheduling algorithm schedules periodic tasks using a static priority policy
with pre-emption. If a lower-priority process is running and a higher-priority process becomes
available to run, it will preempt the lower-priority process.
 Upon entering the system, each periodic task is assigned a priority inversely based on its
period. The shorter the period, the higher the priority; the longer the period, the lower the
priority, this means higher priority is assigned to tasks that require the CPU more often.
 Rate-monotonic scheduling assumes that the processing time of a periodic process is the same
for each CPU burst. That is, every time a process acquires the CPU, the duration of its CPU burst
is the same.
Let’s consider an example. We have two processes, P1 and P2. The periods for P1 and P2 are 50 and
100, respectively that is, p1 = 50 and p2 = 100. The processing times are t1 = 20 for P1 and t2 = 35
for P2.
Initially we must check, whether it is possible to schedule these tasks, P1 & P2, so that each meets
its deadlines, by measuring the CPU utilization of a process Pi which is ti/pi; thus CPU utilization of
P1 is 20/50 = 0.40 and that of P2 is 35/100 = 0.35, for a total CPU utilization of 75 percent is
identified; so P1, P2 can be scheduled, as utilization found to be less than 100%. But practically CPU
utilization is bounded at about 83 percent, in RMS Algorithm.

A. We assign P1 a higher priority than P2 because the period of P1 is shorter than that of P2. P1
starts first and completes its CPU burst at time 20, thereby meeting its first deadline, so P1
work is done in that particular period and it will wait for it’s next period. As P1 is done, P2
starts running at this point and runs until time 50, i.e. for 30ms and it is pre-empted by P1,
although it still has 5 milliseconds remaining in its CPU burst. This is happened because, the
next period time of P1 is started at 50 and P1 has higher priority than P2, so P2 is pre-empted
by P1. We have to note that, the priorities in RMS model are static and remain same for all
burst cycles.
B. P1 completes its CPU burst at time 70 and at this point scheduler resumes P2. P2 completes its
CPU burst at time 75, also meeting its first deadline. The system is idle until time 100, where
periods of P1 & P2 starts again and similar scheduling is done, as in step A.
Rate-monotonic scheduling is considered optimal and if a set of processes cannot be scheduled by
this algorithm, it cannot be scheduled by any other algorithm that assigns static priorities.

Earliest-Deadline-First Scheduling Algorithm - For RTOS
 Earliest-deadline-first (EDF) scheduling schedules aperiodic tasks with dynamically assigned
priorities according to deadline. The earlier the deadline, the higher the priority; the later the
deadline, the lower the priority.
 Under the EDF policy, when a process becomes runnable, it must announce its deadline
requirements to the system. Priorities may have to be adjusted to reflect the deadline of the
newly runnable process. I.e. Priorities are not fixed as we seen in Rate-Monotonic model.
 Unlike the rate-monotonic algorithm, EDF scheduling does not require that processes be
periodic, nor must a process require a constant amount of CPU time per burst.
Let's consider an example to illustrate EDF scheduling, P1 has values of p1 = 50 and t1 = 25 and that
P2 has values of p2 = 80 and t2 = 35.
A. Process P1 has the earliest deadline, so its initial priority of P1 is considered higher than that of
process P2. So Process P1 starts running and completes it’s work by reaching 25 on timeline.
Then next priority process P2 begins running at the end of the CPU burst for P1, i.e. at 25. P2
starts running and after it reaches 50 on time line, it is observed that, P1 is scheduled to run in
that slot; At this moment, the priority of P1 and running P2 is compared; which says that, the
upcoming deadline of P2 is at 80 and the upcoming deadline of P1 is at 100. So P2 is not pre-
empted as it is given the highest priority than P1 at that moment, based on earliest deadline. P2
continued it’s execution and ends at 60, after completing it’s burst time.

B. Now P1 starts execution at this point, i.e. at 60 and continues as per it’s burst time. At 80, P2
is scheduled and it is ready to enter the running state; at this point priority of P1 and P2 are
checked based on the earliest deadlines. It is observed that, P1 has deadline at 100 and P2
has deadline at 160. So P1 is assigned with higher priority than P2 and thus P1 is not pre-
empted by P2. P1 continued and done at 85, and P2 started here and continues till 100, at
which the P1 is ready to enter in to running state, now P1 and P2 are checked for priority
based on the earliest deadlines and it was observed that, P1 has deadline at 150 and P2 has
deadline at 160, so P2 is pre-empted by P1 and P1 started execution and ends at, 125. Nos
the remaining of P2 will start at 125 and ends at 145. After this step, the CPU becomes ideal
till 150 at which P1 is scheduled again.
Theoretically, EDF can schedule processes so that each process can meet its deadline
requirements and CPU utilization will be 100 percent. In practice, however, it is impossible due to
the cost of context switching between processes and interrupt handling.

2.3.1 Synchronization - Background
Two processes running in parallel should cooperate with each other in well synchronized manner. A
cooperating process is one that can affect or be affected by other processes executing in the
system. Cooperating processes can either directly share a logical address space (that is, both code
and data) or be allowed to share data only through files or messages. Concurrent access to shared
data may result in data inconsistency and leads to Race Condition.
Race Condition:
A situation, where several processes access and manipulate the same data concurrently and the
outcome of the execution depends on the particular order in which the access takes place, is called
a race condition. To guard against the race condition above, we need to ensure that only one
process at a time can be manipulating the variable counter. To make such a guarantee, we require
that the processes be synchronized in some way.
Synchronization ensure the orderly execution of cooperating processes that share a logical address
space, so that data consistency is maintained.
Example Race Condition is, read and write operations on a large amount of data are received at
almost the same instant, and the machine attempts to overwrite some or all of the old data while
that old data is still being read.

For example, let int a=5, and there are two processes p1 and p2 that can modify the value of a. p1
adds 2 to a a=a+2 and p2 multiplies a with 2, a=a*2. If both processes modify the value of a at the
same time, then a value depends on the order of execution of the process. If p1 executes first, a will
be 14; if p2 executes first, a will be 12. Here p1 and p2 are falling under race condition. This change
of values due to access by two processes at a time is the cause of the critical section problem.

2.3.2 The Critical-Section Problem
Critical Section:
 Consider a system consisting of n processes {P0, P1, ..., Pn−1}.
Each process has a segment of code, called a critical section,
in which the process may perform operations such as,
changing common variables, updating a table, writing a file,
etc. on the logical address space which is shared to it along
with other processes. The important feature of the system is
that, when one process is executing in its critical section, no
other process is allowed to execute in its critical section. That
is, no two processes are executing in their critical sections at
the same time. The critical-section problem is to design a
protocol that the processes can use to cooperate with each
other.
 Each process must request permission to enter its critical
section. The section of code implementing this request is the
entry section. The critical section may be followed by an exit
section. The remaining code is the remainder section.
General structure of a
typical process P
ENTRY SECTION
EXIT SECTION
{
do
critical section code
remainder section code
}while (true);

A solution to the critical-section problem must satisfy the following three requirements;
Mutual exclusion
If process Pi is executing in its critical section, then no other processes can be executing in their
critical sections.
Progress
If no process is executing in its critical section and some processes wish to enter their critical
sections, then only those processes that are not executing in their remainder sections can
participate in deciding which will enter its critical section next, and this selection cannot be
postponed indefinitely.
Bounded waiting
There exists a bound, or limit, on the waiting time of a process to enter it’s critical section after it
has made a request to enter its critical section and before that request is granted.

2.3.3 Peterson solution
Peterson solution is a classic software-based solution to the critical-section problem. Peterson
solution is restricted to two processes and it makes sure that, those two processes will never
access the critical section at same time. Peterson solution satisfy the requirements (mutual
exclusion, progress, and bounded waiting) to be a solution to the critical-section problem.
 Let’s take two processes P1 and P2. Note that Peterson's solution uses below two data items to
be shared between the two processes;
1. int turn
2. boolean flag[2]
1. int turn
Indicates whose turn it is to enter it's critical section. As this is a shared variable, the value of this is
depends on the particular order in which it is accessed.
2. boolean flag[2]
Used to indicate if a process is ready to enter it's critical section. This is also a shared variable and
the size of this array is 2, i.e. it is used to represent the Boolean value for both the processes.
Understanding through practical approach - functional code
 When P1 wants to enter the critical section, it will declare flag[1]=true saying that it is ready to
enter, and it will assign 2 to the turn variable, offering Process 2 to use the CPU

flag [1] = true;
turn = 2;
while (flag [2]&& turn == [2]);
flag [1] = false;
{
do
}while (true);
 When P1 wants to enter the critical section, it will declare flag[1]=true saying that it is ready to
enter, and it will assign 2 to the turn variable, offering Process 2 to use the CPU. Even though P1
has need to use critical section, it is humbly offering P2 to use the critical section. Let’s see
various possible cases;
CASE 1
Only Process 1 wants to access the critical section; so, in the
code, flag[2] is false, so the while statement in line 3 of entry
section becomes false, and the critical section is accessed by
P1, where after completion of critical section access,
flag[1]=false is executed, i.e. it says that, Process 1 is not
ready to access the critical section, as the access is done.
CASE 2
Only Process 2 wants to access the critical section; so, in the
code, flag[1] is false, so the while statement in line 3 of entry
section becomes false, and the critical section is accessed by
P2, where after completion of critical section access,
flag[2]=false is executed, i.e. it says that, Process 2 is not
ready to access the critical section, as the access is done.
Above code structure is same for Case 2, if
we change the numerical values 1 to 2
and 2 to 1, i.e. Process 1 is changed to
Process 2.
ENTRY
SECTION
EXIT
SECTION

CASE 3
Process 1 and Process 2, both wants to access the critical section. So consider both code modules
starts execution in parallel. Process 1 sets flag [1]=true and turn=2, saying that it is ready to access
the critical section and it asks Process 2 to access the critical section. Similarly, Process 2 sets flag
[2]=true and turn=2, saying that it is ready to access the critical section and it asks Process 1 to
access the critical section.
flag [1] = true;
turn = 2;
while (flag [2]&& turn == 2);
flag [1] = false;
{
do
}while (true);
flag [2] = true;
turn = 1;
while (flag [1]&& turn == 1);
flag [2] = false;
{
do
}while (true);
PROCESS 1 CODE PROCESS 2 CODE
The variable “turn” is
assigned with value 2 by
Process 1 and later by
Process 2 the same
variable “turn” is
assigned with value 1;
remember that “turn” is
shared variable, so it can
be accessed by both
Processes. Now check
the while statement of
Process 1.
ENTRY
SECTION
EXIT
SECTION
ENTRY
SECTION
EXIT
SECTION

If both the conditions in while statement are true, then the execution will be kept running in loop
in that while statement till any one of the conditions become false. So, here in the while statement
of Process 1, there are two statements, flag[2], which is true as the flag[2] is given a true by the
Process 2. And the another condition is turn==2, even though turn is assigned with value 2 by the
Process 1, later turn is assigned with value 1 by Process 2. Here we can see the scenario of race
condition, where several processes access and manipulate the same data concurrently and
the outcome of the execution depends on the particular order in which the access takes
place. So depending up on the order of update, initially P1 assigned 2 to “turn” variable,
later it was rewritten by P2 to 1. So the turn==2 is false, and the while statement is failed,
so the P1 is granted access to critical section. Now in parallel, the while statement of P2 is
also came to execution, so as we seen in P1 scenario, here in P2, flag[1] is true, as P1
declared true. And second condition, turn==1 is also true, so the execution will go on in
loop at this while statement only, it don’t go to further critical section. On other hand, P1
completed it’s work in critical section, and came to remainder section through the exit
section, making flag[1]=false. At this moment, the condition flag[1] in while statement of
P2 becomes false, and thus while statement is false, so P2 will enter in to critical section
and completes it’s work and comes to remainder section through the exit block, stating
flag[2]=false.

Because of the way modern computer architectures perform basic machine-language instructions,
affecting both the processor and the memory, there are no guarantees that Peterson’s solution will
work correctly on such architectures. However, it provides a good algorithmic description of solving
the critical-section problem, it may not work correctly on modern computer architectures.
In above scenario, we have considered that 2 is assigned to turn variable by P1 first and later it is
assigned 1 by P2. So P1 executed it’s critical section first and later P2 executed. If initially turn is
assigned with value 1 by P2 and later P1 assigned value 2, then P2 will be executing first and then
P1.
Peterson solution satisfied the following three requirements specified by Critical Section Problem;
Mutual exclusion
When P1 is executing in critical section, P2 can’t get access to critical section. And when P2 is
executing in critical section, P1 can’t get access to critical section.
Progress
P1 and P2 are not executing in their remainder sections and they participate in deciding which will
enter its critical section next, and the selection has not been postponed and done immediately.
Bounded waiting
While P1 is executing in critical section, the P2 has a waiting time which is in a bound or in limit
only. P2 is not waiting forever.

2.3.4 Hardware support for Synchronization
https://www.scaler.com/topics/operating-system/synchronization-hardware-in-os/

 Operating-systems designers build software tools to solve
the critical section problem. The simplest of these tools is
the mutex lock. (In fact, the term mutex is short for mutual
exclusion). We use the mutex lock to protect critical section
from being attacked by race condition.
 Here a process must acquire the lock before entering a
critical section; it releases the lock when it exits the critical
section. This is done by two functions acquire() & release().
The acquire() function acquires the lock, and the release()
function releases the lock.
 A mutex lock has a shared Boolean variable “available”
whose value indicates if the lock is available or not. If
available is true, the process can access the critical section, if
false, the process will wait. Initially available is true. I.e., If the
lock is available, a call to acquire() succeeds, and the lock is
then considered unavailable. A process that attempts to
acquire an unavailable lock is blocked until the lock is
released. The code definition of acquire() is as follows:
acquire( )
release( )
{
do
}while (true);
acquire()
{
while (!available);
/* busy wait */
available = false;
}
2.3.5 Mutex Locks
ENTRY
SECTION
EXIT
SECTION

release() {
available = true;
}
The code definition of release() is as follows:
Understanding through practical approach -
functional code
 Initially the available is true, as no process is
in critical section. Now consider Process 1
wants to enter in to critical section, and it
called acquire() function, and the while loop
is not satisfied here, as it will get satisfied
only if available is not true. While loop is not
satisfied and the control moves further and
the available is assigned with false. And then
the process 1 successfully passed through
acquire function and it got access to critical
section. In this moment the Process 2 also
wants to access, and it called he acquire()
function,
acquire()
{
while (!available);
available = false;
}
release()
{
available = true;
}
{
do
}while (true);
ENTRY
SECTION
EXIT
SECTION
acquire()
{
while (!available);
available = false;
}
release()
{
available = true;
}
{
do
}while (true);
ENTRY
SECTION
EXIT
SECTION
1. Will move further 2. Will Wait
3. Released Critical Section 4. Will move further
1 2
3
4
PROCESS 1 PROCESS 2

and here the while loop got satisfied, because Process 1 assigned true to the available and the
execution of Process 2 will go in to spin in the same while loop, till the available value becomes true.
Meanwhile Process 1 completed it’s execution in critical section and entered in to exit section and
called release() function, and here the available is assigned with true, at this moment, the while loop
of Process 2 will become false, and it will move to further statements in the entry section, i.e. in the
acquire function, changing the available in to false, and it will enter in to critical section, during this
process no other process can access the critical section. Process 2 will change the available to true,
in the exit section, and then the available can be used in acquire function of any other process.
Mutex lock satisfied the following three requirements specified by Critical Section Problem;
Mutual exclusion
When P1 is executing in critical section, P2 can’t get access to critical section. And when P2 is
executing in critical section, P1 can’t get access to critical section.
Progress
P1 and P2 are not executing in their remainder sections and they participate in deciding which will
enter its critical section next, and the selection has not been postponed and done immediately.
Bounded waiting
While P1 is executing in critical section, the P2 has a waiting time which is in a bound or in limit only.
P2 is not waiting forever.

 The main disadvantage of the implementation given here is that it requires busy waiting. While a
process is in its critical section, any other process that tries to enter its critical section must loop
continuously in the call to acquire(). In fact, this type of mutex lock is also called a spinlock
because the process “spins” while waiting for the lock to become available.
 This continual looping is clearly a problem in a real multiprogramming system, where a single
CPU is shared among many processes. Busy waiting wastes CPU cycles that some other process
might be able to use productively.
 Spinlocks do have an advantage, however, in that no context switch is required when a process
must wait on a lock, and a context switch may take considerable time. Thus, when locks are
expected to be held for short times, spinlocks are useful.
Mutex Locks Disadvantage and Advantage

2.3.6 Semaphores
https://www.scaler.com/topics/operating-system/semaphore-in-os/
https://www.tutorialspoint.com/semaphores-in-operating-system
LINK 1
LINK 2

 Monitor in an operating system is one method for achieving process synchronization. Monitors
concept is a synchronization construct, which means that it is a programming mechanism that
enables multiple processes or threads to coordinate actions. This helps in ensuring that they are
not interfering with each other or producing unexpected results.
 Monitors ensure that only one thread is executed at a critical code section, i.e. Monitors are
dynamic tools that help to manage concurrent access to shared resources in the operating
system. Concurrent access means allowing more than one user to access a computer
simultaneously.
 The monitors’ concept was introduced in the programming language Concurrent Pascal by Per
Brinch Hansen in 1972. Since then, they have been implemented in various programming
languages, like Java, C#, Visual Basic, Ada, and Concurrent Euclid.
Important characteristics of Monitors in OS:
1. We can only run one program at a time inside the monitor.
2. A program cannot access the monitor's internal variable if it is running outside the monitor.
Although, a program can call the monitor's functions.
3. Monitors are a collection of procedures and condition variables that are combined in a special
type of module; that can be seen in Pseudo-code of monitor.
2.3.7 Monitors

 Monitor in OS has a simple pseudo-code similar to how we define a
simple class. This pseudo-code contains; variables_declaration,
condition_variables, various procedures, and an initializing_code
block. In this pseudo code, monitor_name is the name of
the monitor.
 Monitor type contains the declaration of variables and
condition variables (whose values define the state of an
instance of that type), along with the bodies of
procedures that operate on those variables. The monitor
construct ensures that only one process at a time can be
active within the monitor.
 A conditional variable in operating system programming
is a special kind of variable that is used to determine if a
certain condition has been met or not.
 Conditional variables are used to communicate between
threads, promoting the proper synchronization.
PSEUDO - CODE OF MONITOR
monitor monitor_name
{
//declaring shared
variables
variables_declaration;
condition_variables;
procedure p1{ ... };
procedure p2{ ... };
...
procedure pn{ ... };
{
initializing_code;
}
}

 There are two types of operations that we can perform on the condition variables of the
monitor:
1. Wait 2. Signal
 We use the wait instruction in a process if we want to halt the execution of that process till a
certain condition is met, that halted process will be sent to the waiting queue. We use the signal
instruction if we want to continue executing the leading thread in the waiting queue. This function
gives a chance to one of the blocked variables.
 We have to note that, the only operations that can be invoked on a condition variable are wait ()
and signal().
 Monitor Entry Queue contains all of the threads, which are commonly referred to as procedures.
If nothing is executing within the monitor, a thread can execute one of its procedures. Otherwise,
the thread is put into the entry queue and put to sleep. As soon as a thread exits the monitor, it
wakes up the next process in the entry queue. This will happen using the wait and signal
conditions.
 The code for initialization (represented as initializing_code in psudo code) is needed once when
creating the monitors. It is executed when a monitor is initialized. It helps to initialize any shared
data structures that the monitor will use to perform specific tasks.
A monitor can be thought of as a conceptual box. A programmer can put procedures into this box
and the monitor makes him a very simple guarantee: only one procedure within the monitor will
execute at a time.

Advantages of Monitor in OS
 Monitors offer have built-in mutual exclusion making concurrent or parallel programming easier
and less error-prone than semaphore-based solutions. Also Monitors are easier to set up than
semaphores and may be able to handle the timing faults that semaphores cause.
Disadvantages of Monitor in OS
 Monitors must be implemented with the programming language and Monitor increases the
compiler's workload.

2.3.8 Classic Problems of Synchronization
There are number of synchronization problems which represents large class of concurrency-
control problems. These problems are used for testing nearly every newly proposed
synchronization scheme.
1. THE PRODUCER-CONSUMER PROBLEM
 The Producer-Consumer problem is a classical multi-process
synchronization problem, that is we are trying to achieve
synchronization between more than one process. There is
one Producer in the producer-consumer problem, Producer is
producing some items, whereas there is one Consumer that is
consuming the items produced by the Producer. The same
memory buffer is shared by both producers and consumers
which is of fixed-size. The work flow of the Producer is to
produce the item, put it into the memory buffer, and again
start producing items. Whereas the task of the Consumer is
to consume the item from the memory buffer. Below are the
problem scenarios that can be seen in Producer-Consumer
Problem. PRODUCER
CONSUMER

Requirements to avoid Producer-Consumer Problem
A. The producer should produce data only when the buffer is not full. In case it is found that the
buffer is full, the producer is not allowed to store any data into the memory buffer.
B. Data can only be consumed by the consumer if and only if the memory buffer is not empty. In
case it is found that the buffer is empty, the consumer is not allowed to use any data from the
memory buffer.
C. Accessing memory buffer should not be allowed to producer and consumer at the same time.
2. THE READERS-WRITERS PROBLEM
 The readers-writers problem is a classical problem of process synchronization, it relates to a
data set such as a file that is shared between more than one process at a time. Among these
various processes, some are Readers - which can only read the data set; they do not perform
any updates, some are Writers - can both read and write in the data sets.
Requirements to avoid Readers-Writers Problem
A. If two or more than two readers want to access the file at the same point in time there will
be no problem. However, in other situations like when two writers or one reader and one
writer wants to access the file at the same point of time, there may occur some problems.
B. Hence the task is to design the code in such a manner that if one reader is reading then no
writer is allowed to update at the same point of time.

C. Similarly, if one writer is writing no reader is allowed to read the file at that point of time and
if one writer is updating a file other writers should not be allowed to update the file at the
same point of time. However, multiple readers can access the object at the same.
The readers-writers problem addresses the issues with managing synchronization among various
reader and writer process, aiming at there exists no problems with the data sets, i.e. no
inconsistency is generated.

3. THE DINING PHILOSOPHERS PROBLEM
 The dining philosopher's problem is the
classical problem of synchronization
which says that Five philosophers are
sitting around a circular table and their
job is to think and eat alternatively. A
bowl of noodles is placed at the center of
the table along with five chopsticks for
each of the philosophers. To eat a
philosopher needs both their right and a
left chopstick. A philosopher can only eat
if both immediate left and right chopsticks
of the philosopher is available. In case if
anyone of the both immediate left and
right chopsticks of the philosopher are not
available then the philosopher puts down
their other (either left or right) chopstick
and starts thinking again.
NOODLES

Requirements to avoid Dining Philosophers Problem
A. Suppose Philosopher Pi wants to eat, it will enter in Philosopher() function, and execute
take_chopstick[i]; by doing this it holds C0 chopstick after that it execute take_chopstick[(i+1)
% 5]; by doing this it holds C1 chopstick (since i =0, therefore (0 + 1) % 5 = 1)
B. Similarly suppose now Philosopher P1 wants to eat, it will enter in Philosopher() function, and
execute take_chopstick[i]; by doing this it holds C1 chopstick after that it execute
take_chopstick[(i+1) % 5]; by doing this it holds C2 chopstick( since i =1, therefore (1 + 1) % 5 =
2)
Practically using the above code procedure, when P0 got a hold of chop sticks 0 and 1, at same
time P1 wants to eat and try to get hold of chopsticks 1 and 2. But the 1 is already held by P0 and
not available, hence the above code generates problems and produces race condition.

4. SLEEPING BARBER PROBLEM/BARBER’S SHOP PROBLEM
 The Sleeping Barber problem is a classic problem in process synchronization that is used to
illustrate synchronization issues that can arise in a concurrent system.
 There is a barber shop with one barber and a number of chairs for waiting customers.
Customers arrive at random times and if there is an available chair, they take a seat and wait
for the barber to become available. If there are no chairs available, the customer leaves. When
the barber finishes with a customer, he checks if there are any waiting customers. If there are,
he begins cutting the hair of the next customer in the queue. If there are no customers
waiting, he goes to sleep.
 The problem is to write a program that coordinates the actions of the customers and the barber
in a way that avoids synchronization problems, such as deadlock or starvation.
Requirements to avoid Sleeping Barber’s Problem
 One solution to the Sleeping Barber problem is to use semaphores to coordinate access to the
waiting chairs and the barber chair. The solution involves the following steps:
 Initialize two semaphores: one for the number of waiting chairs and one for the barber chair.
The waiting chairs semaphore is initialized to the number of chairs, and the barber chair
semaphore is initialized to zero.
 Customers should acquire the waiting chairs semaphore before taking a seat in the waiting
room. If there are no available chairs, they should leave.

 When the barber finishes cutting a customer’s hair, he releases the barber chair semaphore and
checks if there are any waiting customers. If there are, he acquires the barber chair semaphore
and begins cutting the hair of the next customer in the queue.
 The barber should wait on the barber chair semaphore if there are no customers waiting.
 The solution ensures that the barber never cuts the hair of more than one customer at a time,
and that customers wait if the barber is busy. It also ensures that the barber goes to sleep if
there are no customers waiting.

Event Counters
 Event counters are a mechanism used in operating systems to track and count various events
or activities that occur within the system. These counters can be hardware-based or software-
based, depending on the specific implementation.
 In general, event counters are used for performance monitoring, debugging, profiling, and
resource management purposes. They provide insights into system behaviour, allowing
developers and administrators to analyse and optimize system performance.
Here are a few types of event counters commonly used in operating systems:
1. CPU Performance Counters:
• These are hardware-based counters provided by modern processors to track events related to
the CPU's performance.
• They can measure metrics such as the number of instructions executed, cache hits/misses,
branch predictions, and other low-level CPU activities.
2. Interrupt Counters:
• Interrupt counters keep track of the number of interrupts that occur on the system. Interrupts
are signals generated by hardware devices or software to request attention from the CPU.

• Counting interrupts can help identify devices or software components that are generating
excessive interrupts, which can impact system performance.
3. Page Fault Counters:
• Page fault counters monitor the number of times the operating system needs to fetch data from
the disk because it is not present in physical memory. Page faults are an essential part of virtual
memory management, and tracking these events can help identify memory-related issues and
optimize memory usage.
4. Disk I/O Counters:
• Disk I/O counters track the number of read and write operations performed on storage devices.
These counters provide insights into disk usage patterns and can help identify performance
bottlenecks related to disk I/O.
5. Network Interface Counters:
• Network interface counters monitor various network-related events, such as the number of
packets received or transmitted, errors encountered, and network bandwidth utilization. These
counters assist in network performance analysis and troubleshooting.
Operating systems typically provide APIs or command-line tools to access and query these event
counters. Developers and administrators can use these tools for performance optimization or
debugging purposes.

UNIT - 2 [ 12 Periods ]
Threads and Concurrency: Overview, Multicore Programming, Multithreading Models, Implicit
Threading, Threading Issues.
CPU Scheduling: Basic Concepts, Scheduling Criteria, Scheduling Algorithms, Thread Scheduling,
Multiple-Processor Scheduling, Real-Time CPU Scheduling.
Synchronization: Background, The Critical-Section Problem, Peterson solution, Hardware support
for Synchronization, Mutex Locks, Semaphores, Monitors, Classic Problems of Synchronization.
END OF UNIT 1
SUBJECT CODE - CD/CM/CO/CS/IT (R 20)
DETAILS - IoT IV SEM - MARCH 2023
FACULTY DETAILS - PRUDHVI KIRAN P, Asst. Prof., CSE (IoT), RVR&JC College of Engineering

Operating Systems R20 Unit 2.pptx

More Related Content

Similar to Operating Systems R20 Unit 2.pptx (20)

Recently uploaded (20)

Operating Systems R20 Unit 2.pptx