Operating Systems Lecture Notes: Matthew Dailey

Operating Systems Lecture Notes
Introduction
Matthew Dailey
Some material © Silberschatz, Galvin, and Gagne, 2002
Operating Systems
The software that turns a hunk of electronics into something you can use.
This semester, we will learn how OS’s work.
As users, this helps us get more out of any OS.
As programmers, this helps us

– build our own large end-user applications
– exploit the special features of particular OS’s
Outline
Purpose of operating systems
History of operating systems
Interrupts and system calls
Readings: Silberschatz et al., chapters 1-3

Purpose of Operating Systems
The OS is an
intermediary between
the system’s hardware
and its users.
Also called the kernel:

the one program
always running
Goal of an OS: to provide a convenient and efficient environment

for executing programs.
When there is more than one program or user, an additional goal

is to provide a safe environment.
– Programs should not be able to interfere with other programs.
– Users should not be able to interfere with other user’s programs
or data.
Purpose of an OS also depends on

– what hardware is being used.
– who the users are.
User/programmer point of view

– We don’t want to know all the details of the hardware.
– The OS provides a simple abstract system model.
System point of view

– Resources (CPU time, memory, IO devices, etc) need to be
managed.
– The OS is a resource allocator.
History of Operating Systems
History of Operating Systems
The computer’s main memory address space
Early days: mainframe batch systems Memory location 0
Users would submit a job:

operating
– Stack of punch cards
system
– Includes the program, input data, and control
instructions
Operator would organize jobs and run in batches
– One program resident in memory at any time user program
Slow operators / card readers / output devices mean area (only
CPU underutilized ONE program)
Memory location 512K

History of Operating Systems: Multiprogramming
The computer’s main memory address space
Memory location 0
Multiprogrammed Systems: operating

– Keep more than one running job in memory system
– When one job waits for IO, switch to a
different job job 1
Increases CPU utilization job 2
job 3
job 4
Memory location 512K
Multiprogramming allows time sharing

– Multiple simultaneous users interacting with the system
– CPU switches between jobs fast enough for interactive use
Process execution state diagram:
IO Request
RUNNING BLOCKED
IO Completion
Kernel Selection
READY
 Multiprogramming increased efficiency and time sharing increases

convenience. BUT…
 A single process might monopolize CPU or memory.
 One process might overwrite another’s memory.
 If total memory exceeds system memory, backing store is required.
 System state (program counter, registers, etc) needs to be saved and

restored on every context switch.
Result: added complexity  that’s why we need this course!

History of Operating Systems: Virtual memory
Virtual Memory
– Programs see one large block of memory, possibly bigger
than actual system memory.
– Program memory references get translated into real
hardware addresses.
 Not all of a program’s memory has to be resident at once.
 Simpler abstract model for the programmer.
 Requires hardware support for address translation.
 Requires backing store.

History of Operating Systems: Types of computer systems
Desktop systems:
– Initially simple, with batch operation e.g. MS-DOS
– Evolved multiprogramming and time sharing in 80s and 90s
– Evolved graphical user interfaces
– Maximal convenience for user; efficiency secondary
Multiprocessor systems:
– More than one CPU to divide the workload
– Symmetric multiprocessing: all CPUs run same OS
– Asymmetric multiprocessing: master CPU assigns individual tasks to
slave CPUs
– Increasingly common in network servers and even desktops
Distributed systems:
– Multiple standalone systems interconnected for cooperation
– Client-server systems place shared resources on centralized servers
– Peer-to-peer systems allow ad-hoc cooperation between individuals
Real-time systems:
– Systems with rigid time requirements
e.g. must process images coming from a camera at 30 Hz
– Kernel delays must be bounded. Disks are a bad idea
– Common in robots, automobiles, appliances, etc.
Many different system models have evolved over time, driven by

– Hardware costs
– Efficiency
– Convenience for the user
Interrupts and system calls
Von Neumann Architecture, Modern Style
Von Neumann Architecture, Modern Style
CPU and device controllers operate independently, and are

connected by a shared bus to shared memory.
The memory controller synchronizes access to memory.

Interrupts
Most modern systems are interrupt-driven.
If nothing is happening (no programs are ready to run, no IO devices are

waiting for service, and no users are making requests),
then the system sits idle, waiting for an event.
Events are signaled by interrupts.

• Hardware interrupts: usually triggered when a device enables a line on the system bus,
e.g. IRQn on i386
• Software interrupts (also called traps):
– Software errors (divide by 0, invalid memory access)
– System calls (requests for service by the kernel)
[“Trap” is a metaphor for falling through a door from user space execution to kernel mode execution.]
Interrupts
When a hardware interrupt occurs,

– CPU stops what it is doing and transfers control to an interrupt
service routine (ISR)
– May be different ISRs for different types of interrupts. The list of
ISR locations is called the interrupt vector.
– Example: the Intel 386 architecture contains 16 interrupt lines
(IRQ0-IRQ15), requiring a 16-element interrupt vector.
– After servicing the interrupt, the CPU returns to what it was
previously doing. This requires save and restore of process
context (program counter, registers, etc.).
Interrupts during I/O
For a single process accessing output device:

1. Process generates output but continues.
2. Transfer begins. When done, IO device signals an interrupt.
3. CPU switches to ISR, services the interrupt, then returns to the user process.
Protection
Protection architecture: with resource sharing, processes and their

data must be protected from other processes.
Also, errors detected by hardware (e.g. divide by 0) should not

crash the system. Instead trap to the kernel:
– Kernel logs an error message, dumps process memory, and so on.
– Kernel frees resources associated with the bad process and
continues normal system operation.
Protection
Hardware support for protection: Dual Mode.
Some systems use two modes, e.g. USER and MONITOR mode (aka
PRIVILEDGED mode).
Most modern CPUs support modes.
A trap causes a switch from user to monitor mode.
When kernel completes the system call or error handler, it switches back
to user mode before giving control to a user process.
Interrupt/fault
monitor user
set user mode
I/O protection SYSTEM MEMORY
…
System call system call routine:
Check access privileges
sequence for I/O  Jump to routine for system
call n
MONITOR 
RESIDENT
…

read routine:
perform the read (2) Perform
return control to user the I/O
(1) Trap to …
Monitor
 …
PROGRAM 
USER system call n (e.g. a read) (3) Return
… control
 to user
I/O protection
Typically, all I/O operations are privileged.
User program requesting I/O WHY?
– Issues a system call

– System call generates a software interrupt (trap)
– Trap causes bit flip to MONITOR mode and ISR to run
– Kernel ISR checks whether user process has permission to access
the requested device.
– If legal, executes (or queues) the request then flips the mode bit
back to user mode.
System calls
System calls: the main interface between user programs and

the kernel.
Available as special assembly language instructions or high-

level language function calls.
In Unix, documented in man page section 2

System calls
System call categories:
– Process control (creation, deletion, suspension, load, execute,

get/set attributes, wait, allocate memory)
– File management (creation, deletion, open, close, read, write, seek,
get/set attributes)
– Information maintenance (time-of-day, system data)
– Communications (create channel, delete channel, send, receive,
transfer, attach)
Most systems use message passing and/or shared memory for IPC
System calls
Syscall interface between user processes and kernel (in Unix):

Operating System Structures: System calls
Sequence of system calls for “cp hw1.pdf hw2.pdf”:

– execve(): morph the child process into a “cp” instance
– Setup: many calls to get OS info, read DLLs into memory, etc.
– stat(“hw1.pdf”) to get file information and status
– stat(“hw2.pdf”)
– open(“hw1.pdf”) to open the file
– open(“hw2.pdf”)
– read() get a block of data from first file
– write() write the block of data to the second file
– (repeat many times)
– close() first file
– close() second file
What have we learned?
What the OS does for us.

How the modern OS evolved.
Basic computer architecture: interrupts.
How the OS services user programs via system calls.

Operating Systems Lecture Notes: Matthew Dailey

Uploaded by

Copyright:

Available Formats

Operating Systems Lecture Notes: Matthew Dailey

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Operating Systems Lecture Notes: Matthew Dailey

Uploaded by

Copyright:

Available Formats

Operating Systems Lecture Notes

This semester, we will learn how OS’s work.

As users, this helps us get more out of any OS.

As programmers, this helps us

Purpose of operating systems

History of operating systems

Interrupts and system calls

Readings: Silberschatz et al., chapters 1-3

Also called the kernel:

Goal of an OS: to provide a convenient and efficient environment

When there is more than one program or user, an additional goal

Purpose of an OS also depends on

User/programmer point of view

System point of view

Users would submit a job:

Memory location 512K

Multiprogrammed Systems: operating

Increases CPU utilization job 2

Multiprogramming allows time sharing

Process execution state diagram:

 Multiprogramming increased efficiency and time sharing increases

 One process might overwrite another’s memory.

 If total memory exceeds system memory, backing store is required.

 System state (program counter, registers, etc) needs to be saved and

Result: added complexity  that’s why we need this course!

 Not all of a program’s memory has to be resident at once.

 Simpler abstract model for the programmer.

 Requires hardware support for address translation.

 Requires backing store.

Many different system models have evolved over time, driven by

CPU and device controllers operate independently, and are

The memory controller synchronizes access to memory.

Most modern systems are interrupt-driven.

If nothing is happening (no programs are ready to run, no IO devices are

Events are signaled by interrupts.

When a hardware interrupt occurs,

For a single process accessing output device:

Protection architecture: with resource sharing, processes and their

Also, errors detected by hardware (e.g. divide by 0) should not

Typically, all I/O operations are privileged.

User program requesting I/O WHY?

– Issues a system call

System calls: the main interface between user programs and

Available as special assembly language instructions or high-

In Unix, documented in man page section 2

System call categories:

– Process control (creation, deletion, suspension, load, execute,

Syscall interface between user processes and kernel (in Unix):

Sequence of system calls for “cp hw1.pdf hw2.pdf”:

What the OS does for us.

You might also like