Operating Systems

IS0414
Introduction
 Introduction
 An operating system, or "OS," is software that
communicates with the hardware and allows
other programs to run.
 It is comprised of system software, or the fundamental files
the computer needs to boot up and function
 An operating system (OS) is software that manages
computer hardware and software resources and provides
common services for computer programs.
 The operating system is an essential component of
the system software in a computer system.
 Application programs usually require an operating system to
function.
 Cont . . .
 Common desktop operating systems include Windows,
Mac OS X, and Linux.
 While each OS is different, they all provide a graphical user
interface, or GUI, that includes a desktop and the ability to
manage files and folders.
 The program that users interact with, usually called
• The Shell when it is text based and
• The GUI (Graphical User Interface) when it uses icons
 Which is not part of the operating system, although it uses
the operating system to get its work done.
 Cont . . .
 Hardware is at the bottom, which consists of chips, boards,
disks, a keyboard, a monitor, and similar physical objects
 On top of the hardware is the software
Fig: Where the operating system fits in.
 Cont . . .
 Computers have two modes of operation:
• Kernel mode and User mode.
 The operating system, runs in Kernel mode (also called
supervisor mode).
 In this mode it has complete access to all the hardware and
can execute any instruction the machine is capable of
executing.
 The rest of the software runs in User mode, in which only
a subset of the machine instructions is available.
 Cont . . .
 The user interface program, shell or GUI, is the lowest
level of user-mode software
 This allows the user to start other programs, such as a Web
browser, email reader, or music player.
 These programs, too, make heavy use of the operating
system.
 The placement of the operating system as shown in Fig.
runs on the bare hardware and provides the base for all the
other software.
 Cont . . .
 Important distinction between the operating system and
normal (user mode) software is that if a user does not like a
particular email reader
• User is free to get a different one or
• Write his own if he so chooses;
 But User is not free to write his own clock interrupt
handler, which is part of the operating system and is
protected by hardware against attempts by users to modify
it.
 In many systems there are programs that run in user mode
but help the operating system or perform privileged
functions.
 Cont . . .
 For example
• There is often a program that allows users to change their
passwords.
• It is not part of the operating system and does not run in kernel
mode, but it clearly carries out a sensitive function and has to be
protected in a special way.
 Operating systems differ from user (i.e., application)
programs in ways other than where they reside and are
huge, complex, and long-lived.
 WHAT IS AN OPERATING SYSTEM?
 Other than saying it is the software that runs in kernel
mode.
 Perform two essentially unrelated functions:
• Providing application programmers (and application programs,
naturally) a clean abstract set of resources instead of the messy
hardware ones and
• Managing these hardware resources.
 The Operating System as an Extended
Machine
 The architecture (instruction set, memory organization,
I/O, and bus structure) of most computers at the machine-
language level is primitive and awkward to program,
especially for input/output.
 Operating systems contain many drivers for controlling
I/O devices
 All operating systems provide yet another layer of
abstraction for using disks: files.
 Using this abstraction, programs can create, write, and read
files, without having to deal with the messy details of how
the hardware actually works.
 Cont . . .
 Abstraction is the key to manage all the complexity.
 Good abstractions turn a nearly impossible task into two
manageable ones.
• Defining and implementing the abstractions.
• Using these abstractions to solve the problem at hand.
 One abstraction that almost every computer user
understands is the file
 Job of the operating system is to create good abstractions
and then implement and manage the abstract objects thus
created.
 Cont . . .
 Major tasks of the operating system is to hide the hardware
and present programs (and their programmers) with nice,
clean, elegant, consistent, abstractions to work.
 Operating systems turn the ugly into the beautiful, as
shown in Fig.
Fig: Operating systems turn ugly hardware into beautiful abstractions.
 Cont . . .
 Operating system’s real customers are the application
programs (via the application programmers, of course).
 They are the ones who deal directly with the operating
system and its abstractions.
 But, end users deal with the abstractions provided by the
user interface, either a command-line shell or a graphical
interface.
 The Operating System as a Resource
Manager
 Operating system providing abstractions to application
programs is a top-down view.
 An alternative, bottom-up, view is that, the operating
system is there to manage all the pieces of a complex
system.
 Modern computers consist of processors, memories,
timers, disks, mice, network interfaces, printers, and a wide
variety of other devices
 In the bottom-up view, the job of the operating system is
to provide for an orderly and controlled allocation of the
processors, memories, and I/O devices among the various
programs wanting them.
 Cont . . .
 Modern operating systems allow multiple programs to be in
memory and run at the same time.
 Example of printer.
 Operating systems primary task is to keep track of which
programs are
• Using which resource,
• To grant resource requests,
• To account for usage, and
• To mediate conflicting requests from different programs and
users.
 Cont . . .
 Resource management includes multiplexing (sharing)
resources in two different ways:
• In time and in space.
 When a resource is time multiplexed, different programs or
users take turns using it.
 Example, with only one CPU and multiple programs
• Sharing Printer
 In space multiplexing, each one gets part of the resource.
 Example, main memory is normally divided up among
several running programs
• Single disk holding files from many users
 PROCESSES
 Process: an abstraction of a running program
 Processes are the most important abstractions that
operating systems provide.
 Support the ability to have (pseudo) concurrent operation
even when there is only one CPU available
 Turn a single CPU into multiple virtual CPUs.
 All modern computers often do several things at the same
time
 Web server example:
• Requests come in from all over asking for Web pages
 Cont . . .
 PC Example:
• When the system is booted, many processes are secretly
started
• Waiting for incoming email
• Antivirus program to check for updates, etc.
 All this activity has to be managed, and a
multiprogramming system supporting multiple processes is
very useful.
 In multiprogramming system, the CPU switches from
process to process quickly, running each for tens or
hundreds of milliseconds
 At any one instant the CPU is running only one process
 The Process Model
 In this model, all the runnable software on the computer,
sometimes including the operating system, is organized into
a number of sequential processes, or just processes.
 A process is just an instance of an executing program,
including the current values of the program counter,
registers, and variables.
 Conceptually, each process has its own virtual CPU, but in
reality, the real CPU switches back and forth from process
to process.
 Cont . . .
 But to understand the system, it is much easier to think
about a collection of processes running in (pseudo) parallel
than to try to keep track of how the CPU switches from
program to program.
 This rapid switching back and forth is called
multiprogramming
 Cont . . .
Fig: (a) Multiprogramming four programs.
(b) Conceptual model of four independent, sequential
processes.
(c) Only one program is active at once.
 Cont . . .
 In Fig. (a) A computer multiprogramming four programs in
memory.
 In Fig. (b) Four processes, each with its own flow of
control (i.e., its own logical program counter), and each one
running independently of the other ones.
 There is only one physical program counter, so when each
process runs, its logical program counter is loaded into the
real program counter.
 When completed (for the time being), the physical program
counter is saved in the process’ stored logical program
counter in memory
 Cont . . .
 In Fig. (c) viewed over a long enough time interval, all the
processes have made progress, but at any given instant only
one process is actually running
 The CPU switching back and forth among the processes,
the rate at which a process performs its computation will
not be uniform and probably not even reproducible if the
same processes are run again.
 Thus, processes must not be programmed with built-in
assumptions about timing.
 Example: an audio process that plays music to
accompany a high-quality video run by another device
 Cont . . .
 When a process has critical real-time requirements,
particular events must occur within a specified number of
milliseconds.
 Special measures must be taken to ensure that they do
occur.
 Example of a scientist
 So a process is an activity of some kind.
 It has a program, input, output, and a state.
 A single processor may be shared among several processes,
with some scheduling algorithm being accustomed to
determine when to stop work on one process and service a
different one.
 Process Creation
 Operating systems need some way to create processes.
 Four principal events cause processes to be created:
1. System initialization.
2. Execution of a process-creation system call by a running
process.
3. A user request to create a new process.
4. Initiation of a batch job.
 When an operating system is booted, typically numerous
processes are created.
• Some are foreground processes.
• Others run in the background.
 Cont . . .
 Processes that stay in the background to handle some
activity are called daemons.
 Large systems commonly have dozens of them.
• In UNIX, the ps program can be used to list the running
processes.
• In Windows, the task manager can be used.
 Apart from the processes created at boot time, new
processes can be created afterward as well.
• Running process will issue system calls to create one or more new
processes to help it do its job.
• Creating new processes is particularly useful because work can be
finished quickly.
 Cont . . .
 In both UNIX and Windows systems, after a process is
created, the parent and child have their own distinct
address spaces.
 If either process changes a word in its address space, the
change is not visible to the other process
 Process Termination
 After a process has been created, it starts running and does
whatever its job is.
 Sooner or later the new process created, will terminate,
usually due to one of the following conditions:
1. Normal exit (voluntary).
2. Error exit (voluntary).
3. Fatal error (involuntary).
4. Killed by another process (involuntary).
 Most processes terminate because they have done their
work.
 Cont . . .
 Example:
• When a compiler has compiled the program given to it, the
compiler executes a system call to tell the operating system that it
is finished.
• This call is exit in UNIX and ExitProcess in Windows.
 Second reason for termination is that the process discovers
a fatal error
cc foo.c
• To compile the program foo.c and no such file exists, the compiler
simply announces this fact and exits.
 Cont . . .
 Third reason for termination is an error caused by the
process, often due to a program bug
 Example:
• Executing an illegal instruction,
• Referencing nonexistent memory, or
• Dividing by zero
 Fourth reason a process gets terminated is that, the process
executes a system call telling the operating system to kill
some other process.
 In UNIX this call is kill.
 The corresponding Win32 function is TerminateProcess.
 Process Hierarchies
 When a process creates another process, the parent process
and child process continue to be associated in certain ways.
 The child process can itself create more processes, forming
a process hierarchy
 In UNIX, a process and all of its children and further
descendants together form a process group.
 When a user sends a signal from the keyboard, the signal is
delivered to all members of the process group currently
associated with the keyboard
 Individually, each process can catch the signal, ignore the
signal, or take the default action, which is to be killed by the
signal
 Cont . . .
 Example where the process hierarchy plays a key role
• How UNIX initializes itself when it is started, just after the
computer is booted.
• A special process, called init, is present in the boot image.
• When it starts running, it reads a file telling how many terminals
there are.
• Then it forks off a new process per terminal
• These processes wait for someone to log in.
• If a login is successful, the login process executes a shell to accept
commands.
• These commands may start up more processes, and so forth.
• Thus, all the processes in the whole system belong to a single tree,
with init at the root.
 In Windows no concept of a process hierarchy, all
processes are equal.
 Process States
 Each process is an independent entity, with its own
program counter and internal state.
 Processes often need to interact with other processes.
 One process may generate some output that another
process uses as input.
 In the shell command
cat chapter1 chapter2 chapter3 | grep tree
• The first process, running cat, concatenates and outputs three
files.
• The second process, running grep, selects all lines containing the
word ‘‘tree.’’
 Cont . . .
 Depending on the relative speeds of the two processes it
may happen that grep is ready to run, but there is no input
waiting for it.
 It must block until some input is available.
 When a process blocks, because logically it cannot
continue, as it is waiting for input that is not yet available.
 Also possible for a process that is conceptually ready and
able to run to be stopped because the operating system has
decided to allocate the CPU to another process for a while.
 State diagram showing the three states a process may be in:
 Cont . . .
1. Running (actually using the CPU at that instant).
2. Ready (runnable; temporarily stopped to let another
process run).
3. Blocked (unable to run until some external event happens).
Fig: A process can be in running, blocked, or ready state. Transitions
between these states are as shown.
 Cont . . .
 Four transitions are possible among the three states, as
shown.
• Transition 1 occurs when the operating system discovers that a
process cannot continue right now.
• Transitions 2 and 3 are caused by the process scheduler, a part of
the operating system, without the process even knowing about
them.
• Transition 2 occurs when the scheduler decides that the running
process has run long enough, and it is time to let another process
have some CPU time.
• Transition 3 occurs when all the other processes have had their
fair share and it is time for the first process to get the CPU to run
again
 Cont . . .
• Transition 4 occurs when the external event for which a process
was waiting (such as the arrival of some input) happens.
• If no other process is running at that instant, transition 3 will be
triggered and the process will start running.
• Otherwise it may have to wait in ready state for a little while until
the CPU is available and its turn comes.
 THREADS
 A thread is the smallest unit of processing that can be
performed in an OS.
 A thread exists within a process - that is, a single process
may contain multiple threads.
 In traditional operating systems, each process has an
address space and a single thread of control, that is almost
the definition of a process.
 But, in many situations, it is desirable to have multiple
threads of control in the same address space running in
quasi-parallel, as though they were (almost) separate
processes (except for the shared address space).
 Thread Usage
 Why to have a of process within a process?
 There are several reasons for having these mini-processes,
called threads.
 The main reason for having threads is that in many
applications, multiple activities are going on at once. Some
of these may block from time to time.
 So, by decomposing such an application into multiple
sequential threads that run in quasi-parallel, the
programming model becomes simpler.
 Threads are light weight compared to processes, and are
easier to create and destroy than processes.
 Cont . . .
 Creating a thread goes 10–100 times faster than creating a
process.
 When the number of threads needed changes dynamically
and rapidly, this property is useful to have.
 Another reason for having threads is also a performance
argument.
• Threads yield no performance gain when all of them are CPU
bound, but when there is substantial computing and also
substantial I/O, having threads allows these activities to overlap,
thus speeding up the application.
 Threads are useful on systems with multiple CPUs, where
real parallelism is possible
 Example
Fig. A word processor with three threads
 Cont . . .
 If the program were single-threaded, then
• Whenever a disk backup started, commands from the keyboard
and mouse would be ignored until the backup is finished.
• Alternatively, keyboard and mouse events could interrupt the disk
backup, allowing good performance but leading to a complex
interrupt-driven programming model.
• With three threads, the programming model is much simpler.
• The first thread just interacts with the user.
• The second thread reformats the document when told to.
• The third thread writes the contents of RAM to disk periodically.
 Cont . . .
 Having three separate processes would not work here
because all three threads need to operate on the document.
 So having three threads instead of three processes, they
share a common memory and thus all have access to the
document being edited.
 With three processes this would be impossible.
 Another Example of Thread is Spreadsheet
 Example
 Fig. A multithreaded Web server
 Cont . . .
 Dispatcher thread reads incoming requests for work from the
network.
 After examining the request, it chooses an idle (i.e., blocked)
worker thread and hands it the request, possibly by writing a
pointer to the message into a special word associated with each
thread.
 The dispatcher then wakes up the sleeping worker, moving it
from blocked state to ready state.
 When the worker wakes up, it checks to see if the request can
be satisfied from the Web page cache, to which all threads have
access.
 Cont . . .
 If not, it starts a read operation to get the page from the
disk and blocks until the disk operation completes.
 When the thread blocks on the disk operation,
• Another thread is chosen to run, the dispatcher, in order to
acquire more work, or
• Another worker that is now ready to run.
 Another Example where threads are useful is in
applications that must process very large amounts of data.
• The process could be structured with
• An input thread,
• A processing thread, and
• An output thread
 The Classical Thread Model
 The process model is based on two independent concepts:
• Resource grouping and execution
 Process is a way to group related resources together.
 A process has an address space containing program text
and data, as well as other resources.
 These resources may include open files, child processes,
pending alarms, signal handlers, accounting information,
and more.
 By putting them together in the form of a process, they can
be managed more easily.
 Other concept of a process is a thread of execution, or just
thread.
 Cont . . .
 The thread has a
• Program counter: Keeps track of which instruction to execute
next.
• Registers: which hold its current working variables.
• Stack: which contains the execution history, with one frame for
each procedure called but not yet returned from
 Although a thread must execute in some process, the
thread and its process are different concepts.
 Processes are used to group resources together;
 Threads are the entities scheduled for execution on the
CPU.
 Cont . . .
 What threads add to the process model is to allow multiple
executions to take place in the same process environment,
to a large degree independent of one another.
 Having multiple threads running in parallel in one process
is similar to having multiple processes running in parallel in
one computer.
 Threads share an address space and other resources
 Processes share physical memory, disks, printers, and other
resources.
 Cont . . .
 As threads have some of the properties of processes, they
are sometimes called lightweight processes.
 The term multithreading is used to describe the situation
of allowing multiple threads in the same process
 Cont . . .
Fig: (a) Three processes each with one thread.
(b) One process with three threads.
 Cont . . .
 Fig. (a) shows three traditional processes.
• Each process has its own address space and a single thread of
control.
 In contrast, in Fig. (b) shows a single process with three
threads of control.
 In both cases three threads are there,
• In Fig. (a) each of them operates in a different address space, but
• In Fig. (b) all three of them share the same address space.
 When a multithreaded process is run on a single-CPU
system, the threads take turns running
 Cont . . .
 Different threads in a process are not as independent as
different processes
 All threads have exactly the same address space, means that
they also share the same global variables.
 As every thread can access every memory address within
the process’ address space, one thread can read, write, or
even wipe out another thread’s stack.
 There is no protection between threads because
1. It is impossible, and
2. It should not be necessary.
 Cont . . .
 Where processes may be from different users and which
may be hostile to one another
 A process is always owned by a single user, who has
presumably created multiple threads so that they can
cooperate, not fight.
 Threads can also share the same set of open files, child
processes, alarms, signals, and so on
 Cont . . .
Fig:
• The first column lists some items shared by all threads in a
process.
• The second one lists some items private to each thread.
 Cont . . .
 The items in the first column are process properties, not
thread properties.
 For example, if one thread opens a file, that file is visible to
the other threads in the process and they can read and write
it.
 This is logical, since the process is the unit of resource
management, not the thread.
 If each thread had its own address space, open files,
pending alarms, and so on, it would be a separate process
 Cont . . .
 Like a traditional process (i.e., a process with only one
thread), a thread can be in any one of several states:
• Running,
• Blocked,
• Ready, or
• Terminated.
 A running thread currently has the CPU and is active.
 In contrast, a blocked thread is waiting for some event to
unblock it.
 Cont . . .
 For example,
• When a thread performs a system call to read from the keyboard,
it is blocked until input is typed.
• A thread can block waiting for some external event to happen or
for some other thread to unblock it.
 The transitions between thread states are the same as those
between process states discussed earlier.
 Each thread has its own stack, as illustrated in Fig.
 Cont . . .
 Each thread’s stack contains one frame for each procedure
called but not yet returned from.
 This frame contains the procedure’s local variables and the
return address to use when the procedure call has finished
 For example,
• If procedure X calls procedure Y and
• Y calls procedure Z, then
• While Z is executing, the frames for X, Y, and Z will all be on the
stack.
 Cont . . .
 When multithreading is present, processes usually start with
a single thread present.
 Thread has the ability to create new threads by calling a
library procedure such as thread_create.
 A parameter to thread_create specifies the name of a
procedure for the new thread to run.
 It is not necessary (or even possible) to specify anything
about the new thread’s address space, since it automatically
runs in the address space of the creating thread.
 Sometimes threads are hierarchical
 Cont . . .
 When a thread has finished its work, it can exit by calling a
library procedure, say, thread_exit, It vanishes and is no
longer schedulable.
 thread_join blocks the calling thread until a (specific)
thread has exited
 thread_yield, allows a thread to voluntarily give up the
CPU to let another thread run.
 Implementing Threads in User Space
 There are two main places to implement threads:
• User space and the Kernel.
• And an hybrid implementation is also possible
 First method is to put the threads package entirely in user
space.
 The kernel knows nothing about them, it only manages
ordinary, single-threaded processes.
 Advantage is that a user-level threads package can be
implemented on an operating system that does not support
threads.
 Threads are implemented by a library
 Cont . . .
Fig: A user-level threads package.
 Cont . . .
 All implementations have the same general structure, as
shown in Fig.
 The threads run on top of a run-time system, which is a
collection of procedures that manage threads.
 Like pthread_create, pthread_exit, pthread_join, and
pthread_yield, which has been discussed.
 When threads are managed in user space, each process needs
its own private thread table to keep track of the threads in
that process.
• This table is similar to the kernel’s process table, except that it keeps
track only of the per-thread properties, such as each thread’s
program counter, stack pointer, registers, state, and so forth.
 Cont . . .
 The thread table is managed by the run-time system.
 When a thread is moved to ready state or blocked state,
• The information needed to restart it,
• Is stored in the thread table,
• Exactly the same way as the kernel stores information about
processes in the process table.
 Cont . . .
 When a thread does something that may cause it to become
blocked locally
 For example:
• Waiting for another thread in its process to complete some work,
it calls a run-time system procedure.
• This checks to see if the thread must be put into blocked state.
• If so, it stores the thread’s registers (i.e., its own) in the thread
table, looks in the table for a ready thread to run, and
• Reloads the machine registers with the new thread’s saved values.
• As soon as the stack pointer and program counter have been
switched, the new thread comes to life again automatically.
 Cont . . .
 One key difference with processes is when a thread is
finished running for the moment
 For example,
• When it calls thread_yield, the code of thread yield can save the
thread’s information in the thread table itself.
• It can then call the thread scheduler to pick another thread to run.
• The procedure that saves the thread’s state and the scheduler are
just local procedures, so invoking them is much more efficient
than making a kernel call.
• Among other issues, no context switch is needed, the memory
cache need not be flushed, and so on.
• This makes thread scheduling very fast.
 Cont . . .
 User-level threads also have other advantages.
 Allow each process to have its own customized scheduling
algorithm.
• garbage-collector thread, not having to worry about a thread
being stopped at an inconvenient moment.
• scale better, since kernel threads invariably require some table
space and stack space in the kernel
 Cont . . .
 Drawbacks of threads are:
• How blocking system calls are implemented.
• A thread reads from the keyboard before any keys have been hit
• Another Problem similar to blocking system calls is page faults.
• If the program calls or jumps to an instruction that is not in memory, a
page fault occurs and the operating system will go and get the missing
instruction (and its neighbors) from disk.
• This is called a page fault.
• The process is blocked while the necessary instruction is being located and
read in.
• If a thread causes a page fault, the kernel, unaware of even the existence of
threads, naturally blocks the entire process until the disk I/O is complete,
even though other threads might be runnable
 Cont . . .
• Another problem with user-level thread packages is that if a
thread starts running, no other thread in that process will ever run
unless the first thread voluntarily gives up the CPU
• In a single process, there are no clock interrupts, making it impossible to
schedule processes round-robin fashion
• Another argument is, programmers generally want threads
precisely in applications where the threads block often
• For example: in a multithreaded Web server.
Implementing Threads in the Kernel
Fig: A threads package managed by the kernel.
 Cont . . .
 Considering the kernel knowing about the thread and
managing it.
 No run-time system is needed in each, as shown in Fig.
 There is no thread table in each process.
 Instead, the kernel has a thread table that keeps track of all
the threads in the system.
 When a thread wants to create a new thread or destroy an
existing thread
• It makes a kernel call,
• which then does the creation or destruction by updating the
kernel thread table.
 Cont . . .
 The kernel’s thread table holds each thread’s registers, state,
and other information, similar to user-level threads, but
kept in the kernel
 This information is a subset of the information that
traditional kernels maintain about their single threaded
processes, that is, the process state.
 The kernel also maintains the traditional process table to
keep track of processes
 Hybrid Implementations
 One way is use kernel-level threads and then multiplex
user-level threads onto some or all of them, as shown in
Fig.
Fig: Multiplexing user-level threads onto kernel-level threads
 Cont . . .
 The programmer can determine how many kernel threads to use
and how many user-level threads to multiplex on each one,
when this approach is used.
 This model gives the ultimate in flexibility.
 The kernel is aware of only the kernel-level threads and
schedules those.
 Some of those threads may have multiple user-level threads
multiplexed on top of them.
 These user-level threads are created, destroyed, and scheduled
just like user-level threads in a process that runs on an operating
system without multithreading capability
 Each kernel-level thread has some set of user-level threads that
take turns using it