Transcript ITS 225 (Operating Systems) Lecture Notes

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
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
Purpose of Operating Systems
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 Operating Systems
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
Early days: mainframe batch systems
The computer’s main memory address space
Memory location 0
Users would submit a job:
– Stack of punch cards
– Includes the program, input data, and control
instructions
Operator would organize jobs and run in batches
– One program resident in memory at any time
Slow operators / card readers / output devices mean
CPU underutilized
Memory location 512K
operating
system
user program
area (only
ONE program)
History of Operating Systems: Multiprogramming
The computer’s main memory address space
Memory location 0
Multiprogrammed Systems:
– Keep more than one running job in memory
– When one job waits for IO, switch to a
different job
operating
system
job 1
job 2
Increases CPU utilization
job 3
job 4
Memory location 512K
History of Operating Systems: Multiprogramming
Multiprogramming allows time sharing
– Multiple simultaneous users interacting with the system
– CPU switches between jobs fast enough for interactive use
Process execution state diagram:
RUNNING
IO Request
BLOCKED
IO Completion
Kernel Selection
READY
History of Operating Systems: Multiprogramming
 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
History of Operating Systems: Types of computer systems
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.
History of Operating Systems: Types of computer systems
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 call
sequence for I/O
SYSTEM MEMORY

RESIDENT
MONITOR 

(1) Trap to
Monitor

USER
PROGRAM 

…
system call routine:
Check access privileges
Jump to routine for system
call n
…
read routine:
perform the read
return control to user
…
…
system call n (e.g. a read)
…
(2) Perform
the I/O
(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 highlevel 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.