OS Unit-1-1
OS Unit-1-1
We begin our discussion by looking at the operating system’s role in the overall computer system. A
computer system can be divided roughly into four components: the hardware, the operating system, the
application programs, and a user.
The hardware—the central processing unit (CPU), the memory, and the input/output (I/O) devices—
provides the basic computing resources for the system. The application programs—such as word
processors, spreadsheets, compilers, and web browsers—define the ways in which these resources are
used to solve users’ computing problems. The operating system controls the hardware and coordinates
its use among the various application programs for the various users.
We can also view a computer system as consisting of hardware, software, and data. The operating system
provides the means for proper use of these resources in the operation of the computer system.
The history of operating systems (OS) dates back to the early days of computing and has evolved through
multiple generations. Here’s an overview of their development:
These computers could run only one task at a time and required human intervention for every step.
Introduction of batch processing: Jobs were grouped into batches and processed sequentially.
OSs like GM-NAA I/O (for IBM 704) automated some tasks.
BCA, VVFGC 1
Time-sharing systems: Allowed multiple users to interact with the computer simultaneously (e.g.,
CTSS, MULTICS).
Introduction of UNIX (1969) at Bell Labs by Ken Thompson and Dennis Ritchie.
OSs became more sophisticated, supporting file systems, memory management, and process
scheduling.
The rise of microcomputers (PCs) led to the development of user-friendly operating systems.
Mac OS (1984): Apple introduced the Graphical User Interface (GUI) with the Macintosh.
Windows (1985): Microsoft launched Windows 1.0, bringing GUI to the PC world.
OSs became more advanced with better security, networking, and multi-tasking.
Linux (1991 - Present): Open-source OS with distributions like Ubuntu, Fedora, and Debian.
A modern general-purpose computer system consists of one or more CPUs and a number of device
controllers connected through a common bus that provides access between components and shared
memory (Figure 1.2). Each device controller is in charge of a specific type of device (for example, a disk
drive, audio device, or graphics display). Depending on the controller, more than one device may be
attached. For instance, one system USB port can connect to a USB hub, to which several devices can
connect. A device controller maintains some local buffer storage and a set of special-purpose registers.
BCA, VVFGC 2
The device controller is responsible for moving the data between the peripheral devices that it controls
and its local buffer storage.
Typically, operating systems have a device driver for each device controller. This device driver
understands the device controller and provides the rest of the operating system with a uniform interface
to the device. The CPU and the device controllers can execute in parallel, competing for memory cycles.
To ensure orderly access to the shared memory, a memory controller synchronizes access to the memory.
Operating systems can be categorized based on their functionality and usage. Here are the main types of
operating systems:
BCA, VVFGC 3
Optimized for touch interfaces and mobile hardware.
An Operating System (OS) is system software that manages computer hardware and software resources
and provides services for computer programs. The key functions of an operating system include:
1. Process Management
2. Memory Management
Allocates and deallocates memory space to processes.
BCA, VVFGC 4
Protects against malware and unauthorized access.
System Calls
A System Call is a mechanism that allows user-level processes to request services from the operating
system (OS) kernel. These calls act as an interface between a running program and the OS.
BCA, VVFGC 5
read() – Reads data from a file.
The structure of an operating system defines how its components are organized and interact with each other.
There are several different structures used to design an OS, each with its own advantages and trade- offs.
A system structure for an operating system is like the blueprint of how an OS is organized and how its different
parts interact with each other. Because operating systems have complex structures, we want a structure that is
easy to understand so that we can adapt an operating system to meet our specific needs. Similar to how we break
down larger problems into smaller, more manageable sub problems, building an operating system in pieces is
simpler. The operating system is a component of every segment. The strategy for integrating different operating
BCA, VVFGC 6
system components within the kernel can be thought of as an operating system structure.
Simple Structure
Many operating systems do not have well-defined structures. They started as small, simple, and limited
systems and then grew beyond their original scope. Eg: MS-DOS.
In MS-DOS, the interfaces and levels of functionality are not well separated. Application
programs can access basic I/O routines to write directly to the display and disk drives. Such freedom
leaves MS-DOS in bad state and the entire system can crash down when user programs fail.
UNIX OS consists of two separable parts: the kernel and the system programs. The kernel is further
separated into a series of interfaces and device drivers. The kernel provides the file system, CPU
scheduling, memory management, and other operating-system functions through system
calls.
BCA, VVFGC 7
Figure 2.13 UNIX System Structure
The OS is broken into number of layers (levels). Each layer rests on the layer below it,
and relies on the services provided by the next lower layer.
BCA, VVFGC 8
Bottom layer(layer 0) is the hardware and the topmost layer is the user interface.
A typical layer, consists of data structure and routines that can be invoked by higher-level
layer.
The layers are selected so that each uses functions and services of only lower-level layers. So simplifies
debugging and system verification. The layers are debugged one by one from the lowest and if any layer
doesn’t work, then error is due to that layer only, as the lower layers are already debugged. Thus the
design and implementation is simplified.
A layer need not know how its lower level layers are implemented. Thus hides the operations from higher
layers.
The various layers must be appropriately defined, as a layer can use only lower level
layers.
Less efficient than other types, because any interaction with layer 0 required from top
layer. The system call should pass through all the layers and finally to layer 0. This is an
overhead.
BCA, VVFGC 9
Microkernels
The basic idea behind micro kernels is to remove all non-essential services from the
kernel, thus making the kernel as small and efficient as possible.
The removed services are implemented as system applications.
Most microkernels provide basic process and memory management, and message passing
between other services.
Benefit of microkernel - System expansion can also be easier, because it only involves
adding more system applications, not rebuilding a new kernel.
Mach was the first and most widely known microkernel, and now forms a major
component of Mac OSX.
Disadvantage of Microkernel is, it suffers from reduction in performance due to increases
system function overhead.
Modules
Modern OS development is object-oriented, with a relatively small core kernel and a set
of modules which can be linked in dynamically.
Modules are similar to layers in that each subsystem has clearly defined tasks and
interfaces, but any module is free to contact any other module, eliminating the problems
of going through multiple intermediary layers.
The kernel is relatively small in this architecture, similar to microkernels, but the kernel
does not have to implement message passing since modules are free to contact each other
directly. Eg: Solaris, Linux and MacOSX.
BCA, VVFGC 10
Figure 2.15 Solaris loadable modules
The Max OSX architecture relies on the Mach microkernel for basic system
management services, and the BSD kernel for additional services. Application
services and dynamically loadable modules ( kernel extensions ) provide the rest of
the OS functionality.
Resembles layered system, but a module can call any other module.
Resembles microkernel, the primary module has only core functions and the
knowledgeof how to load and communicate with other modules.
BCA, VVFGC 11
Process Management
Process Concept: A question that arises in discussing operating systems involves what to call all the CPU
activities. Early computers were batch systems that executed jobs, followed by the emergence of time-
shared systems that ran user programs, or tasks. Even on a single-user system, a user may be able to run
several programs at one time: a word processor, a web browser, and an e-mail package. And even if a
computer can execute only one program at a time, such as on an embedded device that does not support
multitasking, the operating system may need to support its own internal programmed activities, such as
memory management.
In many respects, all these activities are similar, so we call all of them processes. Although we personally
prefer the more contemporary term process, the term job has historical significance, as much of operating
system theory and terminology was developed during a time when the major activity of operating systems
was job processing. Therefore, in some appropriate instances we use job when describing the role of the
operating system. As an example, it would be misleading to avoid the use of commonly accepted terms
that include the word job (such as job scheduling) simply because process has superseded job.
BCA, VVFGC 12
when an interrupt occurs, to allow the process to be continued correctly afterward when it is
rescheduled to run.
CPU-scheduling information. This information includes a process priority, pointers to
scheduling queues, and any other scheduling parameters.
Memory-management information. This information may include such items as the value of the
base and limit registers and the page tables, or the segment tables, depending on the memory
system used by the operating system.
Accounting information. This information includes the amount of CPU and real time used, time
limits, account numbers, job or process numbers, and so on.
I/O status information. This information includes the list of I/O devices allocated to the process,
a list of open files, and so on.
Threads
The process model discussed so far has implied that a process is a program that performs a single thread
of execution. For example, when a process is running a word-processor program, a single thread of
instructions is being executed. This single thread of control allows the process to perform only one task
at a time. Thus, the user cannot simultaneously type in characters and run the spell checker. Most modern
operating systems have extended the process concept to allow a process to have multiple threads of
execution and thus to perform more than one task at a time. This feature is especially beneficial on
multicore systems, where multiple threads can run in parallel. A multithreaded word processor could, for
example, assign one thread to manage user input while another thread runs the spell checker.
Process Scheduling
The objective of multiprogramming is to have some process running at all times so as to maximize CPU
utilization. The objective of time sharing is to switch a CPU core among processes so frequently that users
can interact with each program while it is running. To meet these objectives, the process scheduler selects
an available process for program execution on a core. Each CPU core can run one process at a time. For
a system with a single CPU core, there will never be more than one process running at a time, whereas a
multicore system can run multiple processes at one time. If there are more processes than cores, excess
processes will have to wait until a core is free and can be rescheduled. The number of processes currently
in memory is known as the degree of multiprogramming.
Scheduling Queues
As processes enter the system, they are put into a ready queue, where they are ready and waiting to execute
on a CPU’s core This queue is generally stored as a linked list; a ready-queue header contains pointers to
the first PCB in the list, and each PCB includes a pointer field that points to the next PCB in the ready
queue. The system also includes other queues. When a process is allocated a CPU core, it executes for a
while and eventually terminates, is interrupted, or waits for the occurrence of a particular event, such as
the completion of an I/O request. Suppose the process makes an I/O request to a device such as a disk.
Since devices run significantly slower than processors, the process will have to wait for the I/O to become
available. Processes that are waiting for a certain event to occur — such as completion of I/O — are placed
in a wait queue.
CPU Scheduling
A process migrates among the ready queue and various wait queues throughout its lifetime. The role of
the CPU scheduler is to select from among the processes that are in the ready queue and allocate a CPU
core to one of them. The CPU scheduler must select a new process for the CPU frequently. An I/O-bound
BCA, VVFGC 13
process may execute for only a few milliseconds before waiting for an I/O request. Although a CPU-
bound process will require a CPU core for longer durations, the scheduler is unlikely to grant the core to
a process for an extended period. Instead, it is likely designed to forcibly remove the CPU from a process
and schedule another process to run. Therefore, the CPU scheduler executes at least once every 100
milliseconds, although typically much more frequently.
Some operating systems have an intermediate form of scheduling, known as swapping, whose key idea is
that sometimes it can be advantageous to remove a process from memory and thus reduce the degree of
multiprogramming. Later, the process can be reintroduced into memory, and its execution can be
continued where it left off. This scheme is known as swapping because a process can be “swapped out”.
Context Switch
Interrupts cause the operating system to change a CPU core from its current task and to run a kernel
routine. Such operations happen frequently on general-purpose systems. When an interrupt occurs, the
system needs to save the current context of the process running on the CPU core so that it can restore that
context when its processing is done, essentially suspending the process and then resuming it. The context
is represented in the PCB of the process. It includes the value of the CPU registers, the process state, and
memory-management information. Generically, we perform a state save of the current state of the CPU
core, be it in kernel or user mode, and then a state restore to resume operations. Switching the CPU core
to another process requires performing a state save of the current process and a state restore of a different
process. This task is known as a context switch.
Process Creation
During the course of execution, a process may create several new processes. As mentioned earlier, the
creating process is called a parent process, and the new processes are called the children of that process.
Each of these new processes may in turn create other processes, forming a tree of processes. Most
operating systems (including UNIX, Linux, and Windows) identify processes according to a unique
process identifier (or pid), which is typically an integer number. The pid provides a unique value for
each process in the system, and it can be used as an index to access various attributes of a process within
the kernel.
Process Termination
A process terminates when it finishes executing its final statement and asks the operating system to delete
it by using the exit() system call. At that point, the process may return a status value to its waiting parent
process. All the resources of the process including physical and virtual memory, open files, and I/O buffers
are deallocated and reclaimed by the operating system. Termination can occur in other circumstances as
well. A process can cause the termination of another process via an appropriate system call. Usually, such
a system call can be invoked only by the parent of the process that is to be terminated. Otherwise, a user—
or a misbehaving application could arbitrarily kill another user’s processes. Note that a parent needs to
know the identities of its children if it is to terminate them.
Interprocess Communication
Processes executing concurrently in the operating system may be either independent processes or
cooperating processes. A process is independent if it does not share data with any other processes
executing in the system. A process is cooperating if it can affect or be affected by the other processes
executing in the system. Clearly, any process that shares data with other processes is a cooperating
process. There are several reasons for providing an environment that allows process cooperation:
BCA, VVFGC 14
Information sharing. Since several applications may be interested in the same piece of
information, we must provide an environment to allow concurrent access to such information.
Computation speedup. If we want a particular task to run faster, we must break it into subtasks,
each of which will be executing in parallel with the others. Notice that such a speedup can be
achieved only if the computer has multiple processing cores.
Modularity. We may want to construct the system in a modular fashion, dividing the system
functions into separate processes or threads.
Cooperating processes require an inter process communication (IPC) mechanism that will allow them
to exchange data— that is, send data to and receive data from each other. There are two fundamental
models of inter process communication: shared memory and message passing. In the shared-memory
model, a region of memory that is shared by the cooperating processes is established. Processes can then
exchange information by reading and writing data to the shared region. In the message-passing model,
Shared-Memory Systems
Inter process communication using shared memory requires communicating processes to establish a
region of shared memory. Typically, a shared-memory region resides in the address space of the process
creating the shared-memory segment. Other processes that wish to communicate using this shared-
memory segment must attach it to their address space. Recall that, normally, the operating system tries to
prevent one process from accessing another process’s memory. Shared memory requires that two or more
processes agree to remove this restriction. They can then exchange information by reading and writing
data in the shared areas. The form of the data and the location are determined by these processes and are
not under the operating system’s control. The processes are also responsible for ensuring that they are not
writing to the same location simultaneously.
Message-Passing Systems
We showed how cooperating processes can communicate in a shared-memory environment. The scheme
requires that these processes share a region of memory and that the code for accessing and manipulating
the shared memory be written explicitly by the application programmer. Another way to achieve the same
effect is for the operating system to provide the means for cooperating processes to communicate with
each other via a message-passing facility.
Message passing provides a mechanism to allow processes to communicate and to synchronize their
actions without sharing the same address space. It is particularly useful in a distributed environment,
where the communicating processes may reside on different computers connected by a network. For
example, an Internet chat program could be designed so that chat participants communicate with one
another by exchanging messages.
CPU Scheduling
Basic Concepts: In a single-processor system, only one process can run at a time; other processes must wait until
the CPU is free. The objective of multiprogramming is to have some process running at all times in processor, to
maximize CPU utilization.
In multiprogramming, several processes are kept in memory at one time. When one process has to wait,
the operating system takes the CPU away from that process and gives the CPU to another process. This
pattern continues. Every time one process has to wait, another process can take over use of the CPU.
Scheduling of this kind is a fundamental operating- system function. Almost all computer resources are
BCA, VVFGC 10
scheduled before use. The CPU is one of the primary computer resources. Thus, its scheduling is central
to operating-system design.
Scheduling Criteria
Different CPU scheduling algorithms have different properties, and the choice of a particular algorithm
may favour one class of processes over another. Many criteria have been suggested for comparing CPU
scheduling algorithms. The criteria include the following:
CPU utilization - The CPU must be kept as busy as possible. Conceptually, CPU utilization can range from
0 to 100 percent. In a real system, it should range from 40 to 90percent .
Throughput - If the CPU is busy executing processes, then work is done fast. One measure of work is the
number of processes that are completed per time unit, called throughput.
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.
Time spent waiting (to get into memory + ready queue + execution + I/O)
o Waiting time - The total amount of time the process spends waiting in the ready queue.
o Response time - The time taken from the submission of a request until the first responseis
produced is called the response time. It is the time taken to start responding. In interactive
system, response time is given criterion.
It is desirable to maximize CPU utilization and throughput and to minimize turnaround time, waiting
time, and response time.
Scheduling Algorithms
CPU scheduling deals with the problem of deciding which of the processes inthe ready queue is to be
allocated the CPU. They are:
First-Come, First-Served Scheduling
Shortest-Job-First Scheduling
Priority Scheduling
Round-Robin Scheduling
Multilevel Queue Scheduling
Multilevel Feedback-Queue Scheduling
BCA, VVFGC 11
P3 3
If the processes arrive in the order P1, P2, P3, and are served in FCFS order, we get the result shown in
the following Gantt chart, which is a bar chart that illustrates a particular schedule, including the start and
finish times of each of the participating processes:
The waiting time is 0 milliseconds for process P1, 24 milliseconds for process P2, and 27 milliseconds
for process P3. Thus, the average waiting time is (0 + 24 + 27)/3 = 17 milliseconds. If the processes arrive
in the order P2, P3, P1, however, the results will be as shown in the following Gantt chart:
The average waiting time is now (6 + 0 + 3)/3 = 3 milliseconds. This reduction is substantial. 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.
Shortest-Job-First Scheduling
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. We use the term SJF because most people and textbooks use this term to refer to this type
of scheduling.
As an example of SJF scheduling, consider the following set of processes, with the length of the CPU
burst given in milliseconds:
Using SJF scheduling, we would schedule these processes according to the following Gantt chart:
The waiting time is 3 milliseconds for process P1, 16 milliseconds for process P2, 9 milliseconds for
process P3, and 0 milliseconds for process P4. Thus, the average waiting time is (3 + 16 + 9 + 0)/4 = 7
milliseconds. By comparison, if we were using the FCFS scheduling scheme, the average waiting time
would be 10.25 milliseconds.
Round-Robin Scheduling
The round-robin (RR) scheduling algorithm is similar to FCFS scheduling, but preemption is added to
enable the system to switch between processes. A small unit of time, called a time quantum or time slice,
BCA, VVFGC 12
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. 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. The average waiting time under
the RR policy is often long. Consider the following set of processes that arrive at time 0, with the length
of the CPU burst given in milliseconds:
If we use a time quantum of 4 milliseconds, then process P1 gets the first 4 milliseconds. Since it requires
another 20 milliseconds, it is preempted after the first time quantum, and the CPU is given to the next
process in the queue, process P2. Process P2 does not need 4 milliseconds, so it quits before its time
quantum expires. The CPU is then given to the next process, process P3. Once each process has received
1 time quantum, the CPU is returned to process P1 for an additional time quantum. The resulting RR
schedule is as follows:
Let’s calculate 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. If a process’s CPU burst exceeds 1 time quantum, that process is preempted and is put
back in the ready queue. The RR scheduling algorithm is thus preemptive.
Priority Scheduling
The SJF algorithm is a special case of the general priority-scheduling algorithm. A priority is associated
with each process, and the CPU is allocated to the process with the highest priority. Equal-priority
processes are scheduled in FCFS order. An SJF algorithm is simply a priority algorithm where the priority
(p) is the inverse of the (predicted) next CPU burst. The larger the CPU burst, the lower the priority, and
vice versa.
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 this text, 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, · · ·, P5, with the length of the CPU burst given in milliseconds:
BCA, VVFGC 13
Using priority scheduling, we would schedule these processes according to the following Gantt chart:
The average waiting time is 8.2 milliseconds. Priorities can be defined either internally or externally.
Internally defined priorities use some measurable quantity or quantities to compute the priority of a
process. For example, time limits, memory requirements, the number of open files, and the ratio of average
I/O burst to average CPU burst have been used in computing priorities. External priorities are set by
criteria outside the operating system, such as the importance of the process, the type and amount
of funds being paid for computer use, the department sponsoring the work, and other, often political,
factors.
Thread Scheduling
On most modern operating systems it is kernel-level threads—not processes—that are being scheduled by
the operating system. 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).
Multi-Processor Scheduling
Our discussion thus far has focused on the problems of scheduling the CPU in a system with a single
processing core. If multiple CPUs are available, load sharing, where multiple threads may run in parallel,
becomes possible, however scheduling issues become correspondingly more complex. Many possibilities
have been tried; and as we saw with CPU scheduling with a single-core CPU, there is no one best solution.
Traditionally, the term multiprocessor referred to systems that provided multiple physical processors,
where each processor contained one single-core CPU. However, the definition of multiprocessor has
evolved significantly, and on modern computing systems, multiprocessor now applies to the following
system architectures:
Multicore CPUs
Multithreaded cores
NUMA systems
Heterogeneous multiprocessing
BCA, VVFGC 14