ITS 225: Operating Systems Operating Systems Lecture 1 Introduction & Overview Jan 15, 2004 Dr. Matthew Dailey Information Technology Program Sirindhorn International Institute of Technology Thammasat University 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 Administrivia Outline for today s lecture See course information handout, and note: Course web site and discussion board Textbook: Silberschatz, Galvin, Gagne Lecture notes will be posted to the web shortly after each class Upcoming deadlines Try homework 1 by next week Programming assignment 1 will be due in 2 weeks Purpose of operating systems History of operating systems Computer architecture background review Modern operating system structures Readings: Chapters 1-3 1
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 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 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 2
Multiprogrammed Systems: Keep more than one running job in memory When one job waits for IO, switch to a different job Increases CPU utilization 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 Kernel Selection IO Completion 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 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 3
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 4
CPU and device controllers operate independently, and are connected by a shared bus and shared memory. The memory controller synchronizes access to memory. Bootstrapping architecture Interrupt architecture I/O architecture Storage architecture System bootstrap program: Program run initially when the computer is first turned on Stored EEPROM, usually Bootstrap program knows where to find the kernel It finds the kernel, loads it into main memory, and starts it running Protection architecture 5
Kernel initialization: First process is often called init In Unix, typing ps 1 gives me the process for the first process: PID TTY STAT TIME COMMAND 1? S 0:05 init Means the init process (process id 1) is sleeping S and has used 5 sec of CPU time so far. init is usually responsible for initializing communication with devices, and starting other processes that make up the OS Most modern systems are interrupt-driven If no programs are ready to run, no IO devices are waiting for service, and no users are making requests, 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 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: Intel 386 architecture contains 16 interrupt lines (IRQ0-IRQ15), requiring a 16-element interrupt vector. After servicing interrupt, CPU returns to what it was previously doing. Requires save and restore of process context (program counter, registers, etc.). Single process doing output. Process generates output but continues. Transfer begins. When done, IO device signals an interrupt. CPU switches to ISR, services interrupt, then returns to the user process. 6
IO Structure: blocking vs. non-blocking I/O User process requests I/O and wait for completion (blocking): E.g. read a character from the terminal User process issues a read() system call Read() call traps to the kernel, which saves the user process context, sets up registers in the I/O controller, then switches to idle mode (or swaps in another process) I/O controller (a UART chip, perhaps) waits to receive a character from the terminal When character received, I/O controller signals an interrupt. CPU enters ISR, copies the character into the user process memory, and (optionally) wakes the process up I/O Structure: blocking vs. non-blocking I/O: User process requests I/O without wait (non-blocking): E.g. output a character to the terminal User process issues a write() system call Write() traps to the kernel Kernel sets up the transfer Kernel returns control to user process When I/O completes, device signals an interrupt Kernel ISR updates device status Direct Memory Access (DMA): If high-speed devices (e.g. disks) generated interrupt for every memory word, CPU would spend too much time in ISR DMA devices allowed to transfer entire block to memory without CPU intervention Only one interrupt per block is generated Steals memory cycles from CPU, unless memory is multiport Storage Hierarchy Instruction cycle: Fetch instruction to register Decode instruction Fetch arguments to registers Instruction execution Store results Registers: fast, on-chip memory. Usually accessible in one clock cycle. Main memory: large array of volatile memory words directly accessible by CPU. Usually requires several CPU cycles. On-chip cache is used to speed up memory fetches and writes. 7
Storage Hierarchy: Disks Usually cannot store all programs in main memory. Need secondary storage, e.g. magnetic disks. Mechanical arms read from multiple platters Access time depends on: Head seek time Rotational latency Transfer time Very slow compared to memory access times Main-memory cache is used to speed up disk reads and writes Figure copyright Silberschatz, Galvin, and Gagne, 2003 Fast, expensive Storage structure: Caching In general, each level of hierarchy can be used to cache data stored at lower levels. E.g. magnetic disk files can be buffered on an electronic disk Caches increase system complexity due problems with consistency With multiple copies of an object existing at different hierarchy levels, which one is correct? How can changes at one level be propagated to another level? Slow, cheap 8
Protection architecture: with multiprogramming, processes and their data must be protected from other processes. 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 Hardware support for protection: Dual Mode Some systems use two modes, e.g. USER and MONITOR mode (or 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 set user mode user System call for I/O I/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 privileged 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 9
Memory Protection Some memory addresses need protection from any user process Interrupt vector Memory-mapped I/O ports Kernel code and data Memory of other processes Simplest method: base register + limit register Base and limit register example. In user mode, accesses outside the range limit cause a trap. CPU Protection by a Timer We need to prevent individual processes from monopolizing the CPU. Common solution: a timer generates interrupts at fixed intervals. If a program is still running when the timer trips, we trap to a kernel ISR. The OS can then decide whether to kill the process, give it more time, let another process run, etc. 10
Operating System Structures Operating System Structures Components of a typical OS Services provided by a typical OS System call interface OS software structures Virtual machines Components of a typical OS: Process management Main-memory management File management I/O Secondary storage Networking Protection Command line interpreter Each component provides a simple abstraction to other parts of the system E.g. we don t want to be bothered with organization of sectors and cylinders on a disk. But files we understand. What have we learned? What the OS does for us How the modern OS evolved How hardware architecture supports the OS The major components of the OS The services provided by those components Interfaces between the components How OS software architectures are organized Next lecture: Processes 11