01-intro.ppt

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.