Advanced Operating

System
Professor Mangal Sain
 Lecture 1

COURSE INTRODUCTION

lecture slides contains some content adapted from :

Silberschatz textbook authors, John Kubiatowicz (Berkeley)
Anderson textbook, John Ousterhout(Stanford), Prof. Ardalan
Sani,
CONTENTS
• Course Introduction
• Text Book and Reference
• Evaluation

3
SUBJECT INTRODUCTION
 This course examines the important problems in
operating system design and implementation. The
operating system provides an established, convenient,
and efficient interface between user programs and the
bare hardware of the computer on which they run.

 The operating system is responsible for sharing resources

(e.g., disks, networks, and processors), providing common
services needed by many different programs (e.g., file
service, the ability to start or stop processes, and access
to the printer), and protecting individual programs from
interfering with one another.
SUBJECT INTRODUCTION
 The course will start with a brief historical perspective of
the evolution of operating systems over the last fifty
years and then cover the major components of most
operating systems. This discussion will cover the
tradeoffs that can be made between performance and
functionality during the design and implementation of an
operating system.

 Particular emphasis will be given to three major OS

subsystems: process management (processes, threads,
CPU scheduling, synchronization, and deadlock), memory
management (segmentation, paging, swapping), and file
systems; and on operating system support for distributed
systems.
LECTURE NOTES
1. Introduction to Operating Systems and Computer Systems/OS Structures
2 Processes, Threads, Interprocess Communication
3 CPU Scheduling
4 Process Synchronization
5 Deadlocks
6 Memory Management:
7 File Systems
Mid Term
9 Virtualization
10 Parallel Systems
11 Distributed Systems
12 Distributed Objects and Middleware
13 Distributed Subsystems
14 Internet Computing
15 Security
Final Exam

6
BOOK REFERENCE
 Operating System Concepts by
Silberschatz, Abraham; Gagne, Greg;
Galvin, Peter B..
 Distributed system- principle and
paradigms by Andrew S. Tanenbaum
and Maarten Van Steen
 Scientific papers and other material
will be listed during the course and will
be made available through the site
 EVALUATION
 Attendance : 10%
 Mid Term : 20%
 Assignment : 20%
 Participation : 10%
 Final Exam : 40%
Lecture 1 – Part 1

Introduction
 INTRODUCTION
● What is an operating system?
● Operating Systems History
● Simple Batch Systems
● Multiprogrammed Batch Systems
● Time-sharing Systems
● Personal Computer Systems
● Parallel and Distributed Systems
● Real-time Systems
WHAT IS AN OPERATING SYSTEM?
● An OS is a program that acts an intermediary
between the user of a computer and computer
hardware.
● Major cost of general purpose computing is
software.
● OS simplifies and manages the complexity of running
application programs efficiently.
 COMPUTER SYSTEM COMPONENTS
● Hardware
● Provides basic computing resources (CPU, memory, I/O devices).
● Operating System
● Controls and coordinates the use of hardware among application
programs.
● Application Programs
● Solve computing problems of users (compilers, database
systems, video games, business programs such as banking
software).
● Users
● People, machines, other computers
ABSTRACT VIEW OF SYSTEM
User
User User User
1
2 3 .. n

.
compiler assembler Text editor Database
system
System and Application Programs
Operating System

Computer
Hardware
OPERATING SYSTEM VIEWS
● Resource allocator
● to allocate resources (software and hardware) of the
computer system and manage them efficiently.
● Control program
● Controls execution of user programs and operation of I/O
devices.
● Kernel
● The program that executes forever (everything else is an
application with respect to the kernel).
OPERATING SYSTEM ROLES
• Referee
• Resource allocation among users, applications
• Isolation of different users, applications from each other
• Communication between users, applications
• Illusionist
• Each application appears to have the entire machine to itself
• Infinite number of processors, (near) infinite amount of
memory, reliable storage, reliable network transport
• Glue
• Libraries, user interface widgets, …
• Reduces cost of developing softwarea
EXAMPLE: FILE SYSTEMS
• Referee
• Prevent users from accessing each other’s files without
permission
• Illusionist
• Files can grow (nearly) arbitrarily large
• Files persist even when the machine crashes in the middle of a
save
• Glue
• Named directories, printf, …
GOALS OF AN OPERATING SYSTEM
● Simplify the execution of user programs and
make solving user problems easier.
● Use computer hardware efficiently.
● Allow sharing of hardware and software resources.
● Make application software portable and versatile.
● Provide isolation, security and protection among
user programs.
● Improve overall system reliability
● error confinement, fault tolerance, reconfiguration.
WHY SHOULD I STUDY OPERATING
SYSTEMS?
● Need to understand interaction between the hardware
and applications
● New applications, new hardware..
● Inherent aspect of society today
● Need to understand basic principles in the design of
computer systems
● efficient resource management, security, flexibility
● Increasing need for specialized operating systems
● e.g. embedded operating systems for devices - cell phones,
sensors and controllers
● real-time operating systems - aircraft control, multimedia
services
COMPUTER SYSTEM ARCHITECTURE (TRADITIONAL)
SYSTEMS TODAY
Irvine Sensorium
HARDWARE COMPLEXITY
INCREASES
From Berkeley OS course
Moore’s Law: 2X transistors/Chi
p Every 1.5 years Intel Multicore Chipsets

Moore’s
Law

From Hennessy and Patterson, Computer Architecture: A Quantitative

22 App
roach, 4th edition, Sept. 15, 2006
 OS NEEDS TO KEEP PACE WITH
HARDWARE IMPROVEMENTS

$/
SOFTWARE COMPLEXITY INCREASES

From MIT’s 6.033 course

PEOPLE-TO-COMPUTER RATIO OVER TIME
From David Culler (Berkeley)
 Lecture 1 – Part 2

Operating System Spectrum

 OPERATING SYSTEM SPECTRUM

● Monitors and Small Kernels

● special purpose and embedded systems, real-time systems
● Batch and multiprogramming
● Timesharing
● workstations, servers, minicomputers, timeframes
● Transaction systems
● Personal Computing Systems
● Mobile Platforms, devices (of all sizes)
EARLY SYSTEMS - BARE MACHINE (1950S)

Hardware – expensive ; Human – cheap

●Structure
● Large machines run from console
● Single user system
• Programmer/User as operator
● Paper tape or punched cards
●Early software From John Ousterhout slides
● Assemblers, compilers, linkers, loaders, device drivers, libraries of
common subroutines.
●Secure execution
●Inefficient use of expensive resources
● Low CPU utilization, high setup time.
 SIMPLE BATCH SYSTEMS (1960’S)
● Reduce setup time by batching jobs with similar requirements.
● Add a card reader, Hire an operator
● User is NOT the operator
● Automatic job sequencing
● Forms a rudimentary OS.

● Resident Monitor From John Ousterhout slides

● Holds initial control, control transfers to job and then back to monitor.
● Problem
● Need to distinguish job from job and data from program.
SUPERVISOR/OPERATOR CONTROL
● Secure monitor that controls job processing
● Special cards indicate what to do.
● User program prevented from performing I/O

● Separate user from computer IBM 7094

● User submits card deck

● cards put on tape
● tape processed by operator
● output written to tape
● tape printed on printer

● Problems From John Ousterhout slides

● Long turnaround time - up to 2 DAYS!!!
● Low CPU utilization
• I/O and CPU could not overlap; slow mechanical devices.
BATCH SYSTEMS - ISSUES
● Solutions to speed up I/O:
● Offline Processing
● load jobs into memory from tapes, card reading and line
printing are done offline.
● Spooling
● Use disk (random access device) as large storage for
reading as many input files as possible and storing output
files until output devices are ready to accept them.
● Allows overlap - I/O of one job with computation of
another.
● Introduces notion of a job pool that allows OS choose next
job to run so as to increase CPU utilization.
SPEEDING UP I/O
BATCH SYSTEMS - I/O COMPLETION
● How do we know that I/O is complete?
● Polling:
● Device sets a flag when it is busy.
● Program tests the flag in a loop waiting for completion of I/O.
● Interrupts:
● On completion of I/O, device forces CPU to jump to a specific
instruction address that contains the interrupt service
routine.
● After the interrupt has been processed, CPU returns to code
it was executing prior to servicing the interrupt.
 MULTIPROGRAMMING
● Use interrupts to run multiple programs
simultaneously
● When a program performs I/O, instead of polling, execute
another program till interrupt is received.
● Requires secure memory, I/O for each program.
● Requires intervention if program loops
indefinitely.
● Requires CPU scheduling to choose the next job
to run.
TIMESHARING

Hardware – getting cheaper; Human – getting expensive

●Programs queued for execution in FIFO order.
●Like multiprogramming, but timer device
interrupts after a quantum (timeslice).
● Interrupted program is returned to end of FIFO
● Next program is taken from head of FIFO
●Control card interpreter replaced by command
language interpreter.
TIMESHARING (CONT.)

● Interactive (action/response)
● when OS finishes execution of one command, it seeks
the next control statement from user.
● File systems
● online filesystem is required for users to access data and
code.
● Virtual memory
● Job is swapped in and out of memory to disk.
PERSONAL COMPUTING SYSTEMS
Hardware – cheap ; Human – expensive
●Single user systems, portable.
●I/O devices - keyboards, mice, display screens, small
printers.
●Laptops and palmtops, Smart cards, Wireless devices.
●Single user systems may not need advanced CPU
utilization or protection features.
●Advantages:
● user convenience, responsiveness, ubiquitous
PARALLEL SYSTEMS
● Multiprocessor systems with more than one CPU
in close communication.
● Improved Throughput, economical, increased
reliability.
● Kinds:
• Vector and pipelined
• Symmetric and asymmetric multiprocessing
• Distributed memory vs. shared memory
● Programming models:
• Tightly coupled vs. loosely coupled ,message-based vs. shared
variable
PARALLEL COMPUTING SYSTEMS
ILLIAC 2 (UIllinois)
Climate modeling, ear
thquake simulations, g
enome analysis, protei
n folding, nuclear fusi
on research, …..
K-computer(Japan)

Tianhe-1(China)

IBM Blue Gene

Connection Machine (MIT)

DISTRIBUTED SYSTEMS

Hardware – very cheap ; Human – very expensive

● Distribute computation among many processors.
● Loosely coupled -
• no shared memory, various communication lines

● client/server architectures
● Advantages:
• resource sharing
• computation speed-up
• reliability
• communication - e.g. email

● Applications - digital libraries, digital multimedia

DISTRIBUTED COMPUTING SYSTEMS
Globus Grid Computing Toolkit Cloud Computing Offerings

PlanetLab Gnutella P2P Network

REAL-TIME SYSTEMS
● Correct system function depends on timeliness
● Feedback/control loops
● Sensors and actuators
● Hard real-time systems -
● Failure if response time too long.
● Secondary storage is limited
● Soft real-time systems -
● Less accurate if response time is too long.
● Useful in applications such as multimedia, virtual reality.
A PERSONAL COMPUTER TODAY
interaction
● Super AMOLED display ● 13 MP front camera
● Capacitive touchscreen ● 2 MP back camera
(multitouch) ● Accelerometer
● Audio (speaker, microphone)
● Gyroscope
● Vibration
● Proximity sensor
● S pen
● Compass
● 4G LTE ● Barometer
● NFC ● Temperature sensor
● WiFi ● Humidity sensor
● Bluetooth
● Gesture Sensor
● Infrared
● GPS
● 64 GB internal storage (extended
by microSD)
● Adreno 330 GPU
● Hexagon DSP
● Multimedia processor
A PERSONAL COMPUTER TODAY

● Super AMOLED display ● 13 MP front camera

● Capacitive touchscreen ● 2 MP back camera
(multitouch) ● Accelerometer
● Audio (speaker, microphone)
● Gyroscope
● Vibration
● Proximity sensor
● S pen
● Compass
● 4G LTE ● Barometer
● NFC ● Temperature sensor
● WiFi ● Humidity sensor
● Bluetooth
● Gesture Sensor
● Infrared
● GPS
● 64 GB internal storage (extended
by microSD)
sensing
● Adreno 330 GPU
● Hexagon DSP
● Multimedia processor
A PERSONAL COMPUTER TODAY
● Super AMOLED display ● 13 MP front camera
● Capacitive touchscreen ● 2 MP back camera
(multitouch) ● Accelerometer
● Audio (speaker, microphone)
● Gyroscope
● Vibration
● Proximity sensor
● S pen
● Compass
● 4G LTE ● Barometer
● NFC connectivity ● Temperature sensor
● WiFi ● Humidity sensor
● Bluetooth
● Gesture Sensor
● Infrared
● GPS
● 64 GB internal storage (extended
by microSD)
● Adreno 330 GPU
● Hexagon DSP
● Multimedia processor 45
A PERSONAL COMPUTER TODAY
● Super AMOLED display ● 13 MP front camera
● Capacitive touchscreen ● 2 MP back camera
(multitouch) ● Accelerometer
● Audio (speaker, microphone)
● Gyroscope
● Vibration
● Proximity sensor
● S pen
● Compass
● 4G LTE ● Barometer
● NFC ● Temperature sensor
● WiFi ● Humidity sensor
● Bluetooth
● Gesture Sensor
● Infrared
● GPS
● 64 GB internal storage (extended
by microSD)
● Adreno 330 GPU
● Hexagon DSP acceleration
● Multimedia processor 46
OPERATING SYSTEMS ARE EVERYWHERE
OPERATING SYSTEMS ARE EVERYWHERE
INFO-TAINMENT!!

49
SUMMARY OF LECTURE
● What is an operating system?
● Early Operating Systems
● Simple Batch Systems
● Multiprogrammed Batch Systems
● Time-sharing Systems
● Personal Computer Systems
● Parallel and Distributed Systems
● Real-time Systems
 Lecture 1 – Part 3

Computer System & OS Structures

COMPUTER SYSTEM & OS STRUCTURES
• Computer System Organization

• Operational Flow and hardware protection

• System call and OS services

• Storage architecture

• OS organization

• OS tasks

• Virtual Machines
COMPUTER SYSTEM ORGANIZATION
CPU EXECUTION Addr 232-1
R0
…
R31
F0
Fetch …
… Exec Data1
F30
PC Data0
Inst237
Inst236
…
• Execution sequence: Inst5
• Fetch Instruction at PC Inst4
• Decode Inst3 PC
• Execute (possibly using registers) Inst2 PC
• Write results to registers/mem Inst1 PC
• PC = Next Instruction(PC) Inst0 PC
• Repeat

Addr 0
From Berkeley OS course
COMPUTER SYSTEM ORGANIZATION

I/O devices
I/O DEVICES

• I/O devices and the CPU execute concurrently.

• Each device controller is in charge of a particular
device type
• Each device controller has a local buffer. I/O is from the
device to local buffer of controller
• CPU moves data from/to main memory to/from the
local buffers
INTERRUPTS
• Interrupt transfers control to the
interrupt service routine
• Interrupt Service Routine: Segments of
code that determine action to be taken for
interrupt.
• Determining the type of interrupt
• Polling: same interrupt handler called for all
interrupts, which then polls all devices to
figure out the reason for the interrupt
• Interrupt Vector Table: different interrupt
handlers will be executed for different
interrupts
INTERRUPT HANDLING

• OS preserves the state of the CPU

• stores registers and the program counter (address of
interrupted instruction).
• What happens to a new interrupt when the CPU
is handling one interrupt?
• Incoming interrupts can be disabled while another interrupt is
being processed. In this case, incoming interrupts may be lost or
may be buffered until they can be delivered.
• Incoming interrupts can be masked (i.e., ignored) by software.
• Incoming interrupts are delivered, i.e., nested interrupts.
DIRECT MEMORY ACCESS (DMA)
• Typically used for I/O devices
with a lot of data to transfer (in
order to reduce load on CPU). Memory

• Device controller transfers

blocks of data from buffer
storage directly to main
memory without CPU
intervention.
• Device controller interrupts CPU
I/O devices
I/O instructions
CPU on completion of I/O
• Only one interrupt is generated
per block, rather than one per
byte (or word).
PROCESS ABSTRACTION

60
 PROCESS ABSTRACTION
• Process: an instance of a program, running
with limited rights
 PROCESS ABSTRACTION AND RIGHTS
• Process: an instance of a program, running
with limited rights

• Address space: set of rights of a process

• Memory that the process can access

• Other permissions the process has (e.g., which

system calls it can make, what files it can access)
HARDWARE PROTECTION

• CPU Protection:
• Dual Mode Operation
• Timer interrupts

• Memory Protection

• I/O Protection
CPU PROTECTION

• How to prevent a process from executing

indefinitely?
CPU PROTECTION
• Timer - interrupts computer after specified period to
ensure that OS maintains control.
• Timer is decremented every clock tick.
• When timer reaches a value of 0, an interrupt occurs.

• Timer is commonly used to implement time

sharing.
• Timer is also used to compute the current time.

• Programming the timer can only be done in the

kernel since it requires privileged instructions.
MEMORY PROTECTION

• When a process is running, only memory in that process

address space must be accessible.
• When executing in kernel mode, the kernel has
unrestricted access to all memory.
• Must provide memory protection at least for the interrupt
vector and the interrupt service routines.
I/O PROTECTION

• All I/O instructions are privileged instructions.

• Must ensure that a user program could never gain

control of the computer in kernel mode, e.g., a user
program must not be able to store a new address
in the interrupt vector.
QUESTION

• Given the I/O instructions are privileged, how do

users perform I/O?
QUESTION

• Given the I/O instructions are privileged, how do

users perform I/O?

• Via system calls - the method used by a process to

request action by the operating system.
 SYSTEM CALLS

• User code can issue a syscall, which causes a trap

• Kernel handles the syscall
 SYSTEM CALLS
• Interface between applications
and the OS.
• Application uses an
assembly instruction to trap into
the kernel
• Some higher level languages
provide wrappers for system
calls (e.g., C)
• System calls pass parameters
between an and OS via registers
or memory, memory tables or
stack.
• Linux has about 300 system
calls
• read(), write(), open(), close(),
fork(), exec(), ioctl(),…..
SYSTEM SERVICES OR SYSTEM PROGRAMS

• Convenient environment for program development

and execution.
• Command Interpreter (i.e., shell) - parses/executes other
system programs
• Window management
• System libraries, e.g., libc
COMMAND INTERPRETER SYSTEM

• Commands that are given to the operating system

via command statements that execute
• Process creation and deletion, I/O handling, secondary
storage management, main memory Management, file
system access, protection, networking, etc.
• Obtains the next command and executes it.
• Programs that read and interpret control
statements also called -
• Command-line interpreter, shell (in UNIX)
STORAGE STRUCTURE

• Main memory - only large storage media that the

CPU can access directly.
• Secondary storage - has large nonvolatile storage
capacity.
• Magnetic disks - rigid metal or glass platters covered with
magnetic recording material.
• Disk surface is logically divided into tracks, subdivided into
sectors.
• Disk controller determines logical interaction between device
and computer.
STORAGE HIERARCHY

• Storage systems are organized in a hierarchy

based on
• Speed
• Cost
• Volatility

• Caching - process of copying information into

faster storage system; main memory can be
viewed as fast cache for secondary storage.
STORAGE DEVICE HIERARCHY
OS TASK: PROCESS MANAGEMENT
• Process - fundamental concept in OS
• Process is an instance of a program in execution.
• Process needs resources - CPU time, memory, files/data
and I/O devices.
• OS is responsible for the following process
management activities.
• Process creation and deletion
• Process suspension and resumption
• Process synchronization and interprocess communication
• Process interactions - deadlock detection, avoidance and
correction
OS TASK: MEMORY MANAGEMENT

• Main Memory is an array of addressable words or

bytes that is quickly accessible.
• Main Memory is volatile.
• OS is responsible for:
• Allocate and deallocate memory to processes.
• Managing multiple processes within memory - keep track of which
parts of memory are used by which processes. Manage the
sharing of memory between processes.
• Determining which processes to load when memory becomes
available.
OS TASK: SECONDARY STORAGE AND I/O MANAGEMENT

• Since primary storage (i.e., main memory) is

expensive and volatile, secondary storage is
required for backup.
• Disk is the primary form of secondary storage.
• OS performs storage allocation, free-space management,
etc. and disk scheduling.
• I/O system in the OS consists of
• Device driver interface that abstracts device details
• Drivers for specific hardware devices
OS TASK: FILE SYSTEM MANAGEMENT
• File is a collection of related information -
represents programs and data.

• OS is responsible for
• File creation and deletion
• Directory creation and deletion
• Supporting primitives for file/directory manipulation.
• Mapping files to disks (secondary storage).
• Backup files on archival media (tapes).
OS TASK: PROTECTION AND SECURITY

• Protection mechanisms control access of processes to

user and system resources.
• Protection mechanisms must:
• Distinguish between authorized and unauthorized
use.
• Specify access controls to be imposed on use.
• Provide mechanisms for enforcement of access
control.
• Security mechanisms provide trust in system and
privacy
• authentication, certification, encryption etc.
OPERATING SYSTEMS: HOW ARE THEY
ORGANIZED?

• Simple
• Only one or two levels of code
• Layered
• Lower levels independent of upper levels
• Modular
• Core kernel with Dynamically loadable modules
• Microkernel
• OS built from many user-level processes
OS STRUCTURE - SIMPLE APPROACH

• MS-DOS - provides a lot of functionality in little

space.
• Not divided into modules, Interfaces and levels of
functionality are not well separated
ORIGINAL UNIX SYSTEM STRUCTURE
• Limited structuring, has 2 separable parts
• Systems programs
• Kernel
• everything below system call interface and above physical hardware.
• Filesystem, CPU scheduling, memory management
LAYERED OS STRUCTURE
• OS divided into number of
layers - bottom layer is
hardware, highest layer is
the user interface.

• Each layer uses functions

and services of only lower-
level layers.

• THE Operating System and

Linux Kernel has successive
layers of abstraction.
 MONOLITHIC VS. MICROKERNEL OS
•Monolithic OSes have large kernels with a lot of components
• Linux, Windows, Mac

•Microkernels moves as much from the kernel into “user” space

• Small core OS components running at kernel level
• OS Services built from many independent user-level processes

•Communication between modules with message passing

•Benefits:
• Easier to extend a microkernel
• Easier to port OS to new architectures
• More reliable and more secure (less code is running in kernel mode)
• Fault Isolation (parts of kernel protected from other par
•Detriments:
• Performance overhead severe for naïve implementation
 A MICROKERNEL OS

Slide adapted from http://web.cecs.pdx.edu/~walpole/class/cs533/fall2015/home.html

VIRTUAL MACHINES

Physical Machine

Application

OS

Hardware
VIRTUAL MACHINES

Virtual Machine 1 Virtual Machine 2 Virtual Machine 3

Application Application Application

OS OS OS

Virtual Machine Monitor (VMM) (aka Hypervisor)

Hardware
VIRTUAL MACHINES

• Use cases
●Resource configuration
●Running multiple OSes, either the same or different
OSes
●Run existing OS binaries on different architecture
SUMMARY OF LECTURE SET 1

• What is an operating system?

• Operating systems history
• Computer system and operating system structure