What is an Operating System?

A program and an interface

 An abstract virtual machine
 A set of abstractions that simplify application design
 Files instead of “bytes on a disk”

For any OS area (CPU scheduling, file systems, memory

Operating Systems: management), begin by asking two questions
Basic Concepts and History  What’s the hardware interface? (The Physical Reality)
 What is the application interface? (The Nicer Interface)

Key questions:
 Why is the application interface defined the way it is?
 Should we push more functionality into applications, the OS, or
the hardware?
 What are the tradeoffs between programmability, complexity,
and flexibility?
1 2

Operating System Functions Why do we need operating systems?

Service provider
 Provide standard facilities Convenience
File system
v
 Provide a high-level abstraction of physical resources
v Standard libraries
v Window system  Enable the construction of more complex software systems
…
v
 Enable portable code
Coordinator: three aspects
 Security: prevent jobs from interfering with each other
 Communication: enable jobs to interact with each other
Efficiency
 Resource management: facilitate sharing of resources across  Share limited or expensive physical resources
jobs
 Provide protection
Examples
 Single-function devices (embedded controllers, Nintendo, …)
v OS provides a collection of standard services
 Multi-function/application devices (workstations and servers)
v OS manages application interactions

3 4
Evolution of Operating Systems History of Operating Systems: Phases

Why do operating systems change? Phase 1: Hardware is expensive, humans are cheap
 Key functions: hardware abstraction and coordination
 User at console: single-user systems
 Principle: Design tradeoffs change as technology changes
 Batching systems
 Underlying technology has changed immensely over the past two decades !!
 Multi-programming systems
Comparing computing systems from 1981 and 2000

Phase 2: Hardware is cheap, humans are expensive

1981 2000 Factor  Time sharing: Users use cheap terminals and share servers
MIPS 1 1000 1000
$/SPECInt $100K $2 50000 Phase 3: Hardware is very cheap, humans are very expensive
DRAM size 128KB 256MB 2000  Personal computing: One system per user
Disk size 10MB 10GB 1000  Distributed computing: lots of systems per user
Net BW 9600 bps 100 Mb/s 10000
Address bits 16 64 4 Phase 4: Richer services
Users/machine 100 <1 100  Real-time operating systems
5 6

A Brief History of Operating Systems

History of Operating Systems: Phases Hand programmed machines (‘45-‘5 5 )

Phase 1: Hardware is expensive, humans are cheap

 User at console: single-user systems Single user systems
 Batching systems
 Multi-programming systems OS = loader + libraries of common subroutines

Phase 2: Hardware is cheap, humans are expensive

 Time sharing: Users use cheap terminals and share servers
Problem: low utilization of expensive components

Phase 3: Hardware is very cheap, humans are very expensive

time device busy
 Personal computing: One system per user = % utilization
observation interval
 Distributed computing: lots of systems per user

Phase 4: Richer services

 Real-time operating systems
7 8
 Batch/Off-line processing (‘55-‘65) Batch processing (‘55-‘6 5 )

Batching v. sequential execution of jobs Operating system = loader + sequencer + output processor

Card Reader: Read

Read Job
Job 11 Job
Job 22 Job
Job 33 User Data
CPU: Execute Job 1 Job
Job 22 Job
Job 33
User Program
Printer: Print
Print Job
Job 11 Job
Job 22 Job
Job 33
Tape
Tape “System Software” Tape
Tape

Operating System
Card Reader: Read
Read Batch
Batch 11 Batch
Batch 22 Batch
Batch 33

CPU: Execute Batch 1 Batch

Batch 22 Batch
Batch 33 Compute
Card
Card
Printer: Print
Print Batch
Batch 11 Batch
Batch 22 Batch
Batch 33 Tape Printer
Printer
Reader
Reader Tape Tape
Tape

Input Output
9 10

Multiprogramming (‘65-‘80) Multiprogramming (‘65-‘80)

Keep several jobs in memory and multiplex CPU Keep several jobs in memory and multiplex CPU
between jobs between jobs
program PP
program Simple, “synchronous” input: Program 1 OS
I/O
begin Device
begin What to do while we wait
User Program n :: User Program n main{
Read(var) for the I/O device?
Read(var)
:: read{
...

...

k: read()
end PP
end
User Program 2 User Program 2 startIO()
waitIO()
system call Read
system call Read()()
User Program 1 begin
begin User Program 1
StartIO(input device)
StartIO(input device) endio()
“System Software” WaitIO(interrupt)
WaitIO(interrupt) “System Software” interrupt
EndIO(input
EndIO(inputdevice)
device) k+1:
:: }
Operating System Operating System
end Read
end Read
}
11 12
 Multiprogramming (‘65-‘80) History of Operating Systems: Phases

Keep several jobs in memory and multiplex CPU Phase 1: Hardware is expensive, humans are cheap
between jobs  User at console: single-user systems
 Batching systems
I/O
Program 1 OS Program 2 Device  Multi-programming systems
User Program n main{
Phase 2: Hardware is cheap, humans are expensive
read{
...

k: read()  Time sharing: Users use cheap terminals and share servers
User Program 2 startIO()
main{
schedule() Phase 3: Hardware is very cheap, humans are very expensive
}
User Program 1  Personal computing: One system per user
endio{
“System Software” interrupt  Distributed computing: lots of systems per user
k+1: schedule()
}
Operating System Phase 4: Richer services
}  Real-time operating systems
13 14

Timesharing (‘70- ) History of Operating Systems: Phases

A timer interrupt is used to multiplex CPU among Phase 1: Hardware is expensive, humans are cheap
 User at console: single-user systems
jobs
Program 1 OS Program 2  Batching systems
main{  Multi-programming systems
User Program n
timer Phase 2: Hardware is cheap, humans are expensive
...

interrupt
k: schedule{  Time sharing: Users use cheap terminals and share servers
main{
User Program 2 }
Phase 3: Hardware is very cheap, humans are very expensive
timer
User Program 1 interrupt  Personal computing: One system per user
schedule{
“System Software”  Distributed computing: lots of systems per user
k+1: }
Operating System timer Phase 4: Richer services
interrupt
schedule{  Real-time operating systems
15 16
Operating Systems for PCs Distributed Operating Systems

Personal computing systems Typically support distributed services

 Sharing of data and coordination across multiple systems
 Single user
Possibly employ multiple processors
 Utilization is no longer a concern
 Loosely coupled v. tightly coupled systems
 Emphasis is on user interface and API
High availability & reliability requirements
 Many services & features not present

User
User User
User
Evolution Program
Program Program
Program
OS
OS OS file
file system
system
 Initially: OS as a simple service provider process process name
name services
services
process process management
management
(simple libraries) management
management memory
memory management
management mail
mail services
services

 Now: Multi-application systems with

support for coordination CPU
CPU CPU
CPU CPU
CPU

NetworkLAN/WAN
17 18

Richer Operating Systems

History of Operating Systems: Phases Real-time operating systems

Phase 1: Hardware is expensive, humans are cheap A system with a dual notion of correctness
 User at console: single-user systems  Logical correctness — “it does the right thing”
 Batching systems
 Temporal correctness — “it does it on time”
 Multi-programming systems

Phase 2: Hardware is cheap, humans are expensive A system wherein predictability is more important
 Time sharing: Users use cheap terminals and share servers than performance
Example: Digital video playout
Phase 3: Hardware is very cheap, humans are very expensive
 Personal computing: One system per user /* Main processing loop */
loop
 Distributed computing: lots of systems per user data = read( network)
video_frame = decompress(data)
write( frame_buffer, video_frame)
Phase 4: Richer services end loop
 Real-time operating systems
Timing constraint: Execute loop once every 33 ms.
19 20
 Course Overview
Real-time Operating Systems: Issues

Digital video processing loop:

/* Main processing loop */
OS Structure, Processes and Process Management
loop
data = read( network)
video_frame = decompress(data)
Threads and concurrent programming
display( video_frame)
end loop  Thread coordination, mutual exclusion, monitors
Timing constraint: Execute loop once every 33 ms.
 Deadlocks

CPU scheduling
Dedicated system — real-time performance iff
time(loop) ≤ 33 ms Memory management
 Real-time computing is a programming problem
(“Just buy a faster processor”) Secondary storage management & file systems

Distributed systems & networking

Multi-programmed system — real-time performance iff … ???
 Real-time computing is an operating systems problem

21 22