Operating Systems Lecture NotesOperating Systems Lecture Notes

IntroductionIntroduction

Matthew DaileySome material © Silberschatz, Galvin, and Gagne, 2002

Operating SystemsOperating 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

OutlineOutline

Purpose of operating systems

History of operating systems

Interrupts and system calls

Readings: Silberschatz et al., chapters 1-3

Purpose of Operating SystemsPurpose of Operating Systems

Purpose of Operating SystemsPurpose 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 SystemsPurpose 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 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 SystemsHistory of Operating Systems

History of Operating SystemsHistory of Operating Systems

Early days: mainframe batch systems

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

The computer’s main memory address space

operatingsystem

user programarea (only

ONE program)

Memory location 0

Memory location 512K

History of Operating Systems: MultiprogrammingHistory of Operating Systems: Multiprogramming

Multiprogrammed Systems:– Keep more than one running job in memory– When one job waits for IO, switch to a

different job

Increases CPU utilization

operatingsystem

job 1

Memory location 0

Memory location 512K

job 2

job 3

job 4

The computer’s main memory address space

History of Operating Systems: MultiprogrammingHistory 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

READY

BLOCKEDIO Request

IO CompletionKernel Selection

History of Operating Systems: MultiprogrammingHistory 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 memoryHistory 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 systemsHistory 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.

History of Operating Systems: Types of computer systemsHistory of Operating Systems: Types of computer systems

Many different system models have evolved over time, driven by

– Hardware costs– Efficiency– Convenience for the user

History of Operating Systems: Types of computer systemsHistory of Operating Systems: Types of computer systems

Interrupts and system callsInterrupts and system calls

Von Neumann Architecture, Modern StyleVon Neumann Architecture, Modern Style

Von Neumann Architecture, Modern StyleVon 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.

InterruptsInterrupts

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.]

InterruptsInterrupts

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/OInterrupts 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.

ProtectionProtection

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.

ProtectionProtection

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.

monitor user

Interrupt/fault

set user mode

I/O protectionI/O protection

System callsequence for I/O

SYSTEM MEMORY

…system call routine:

Check access privilegesJump to routine for system call n

…read routine:

perform the readreturn control to user

…

RESIDENTMONITOR

USERPROGRAM

…system call n (e.g. a read)…

(1) Trap toMonitor

(2) Performthe I/O

(3) Returncontrolto user

I/O protectionI/O protection

Typically, all I/O operations are privileged.

User program requesting I/O

– 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.

WHY?

System callsSystem 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 callsSystem 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 callsSystem calls

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

Operating System Structures: System callsOperating 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 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.