Meet the OS Software that manages a computer s resources - PowerPoint PPT Presentation

Meet the OS Software that manages a computer’ s resources Introduction Makes it easier to write the applications you want to write CS 4410 Makes you want to use the applications you wrote by running them efficiently OS wears many hats What is an OS? Referee An Operating System implements a virtual Manages shared resources: CPU, memory, disks, networks, machine whose interface is more convenient* displays, cameras… that the raw hardware interface Illusionist Look! Infinite memory! Your Application Application Application Application Application VM own private processor! OS Interface Interface Operating System Glue Physical Machine Interface Hardware Offers a set of common services (e.g., UI routines) * easier to use, simpler to code, more reliable, more secure... Separates apps from I/O devices “All the code you did not write”

OS as Referee OS as Illusionist Resource allocation Appearance of resources not physically present Multiple concurrent tasks, how does OS decide who Virtualization gets how much? Application Application Application Application Application VM Processor, memory, Interface Operating System Isolation screen space, disk, network Hardware A faulty app should not disrupt other apps or OS Communication/Coordination Apps need to coordinate and share state OS as Illusionist OS as Illusionist Appearance of resources not physically present Appearance of resources not physically present Virtualization Atomic operations Application Application Application Application Application VM Processor, memory, HW guarantees atomicity at the word level… Interface Operating System screen space, disk, What happens during concurrent updates to network Hardware complex data structures? The entire computer What is a computer crashes while writing a file Fooling the block? Application Application Application Application Application VM illusionist itself! At the hardware level, packets are lost Interface Guest OS 1 Guest OS 2 Eases debugging, Reliable communication channels VMM portability, VM isolation Interface Hardware

OS as Glue A Short History of Offers standard services to simplify app design Operating Systems and facilitate sharing Send/Receive byte streams Read/Write files Pass messages Share memory UI Decouples HW and app development Hand programmed History of machines (1945-1955) Operating Systems Phase 1: Hardware is expensive, humans are cheap Single user systems User at console: single-user systems Batching systems OS = loader + libraries of Multi-programming systems common subroutines Problem: low utilization of expensive components time device busy observation interval = % utilization

Batch Processing Multiprogramming (1955-1965) (1965-1980) Operating system = loader + sequencer + output processor Keep several jobs in memory and multiplex CPU between jobs program P User Data begin User Program n : User Program Read(var) ... : 
 Tape Tape end P “System Software” User Program 2 User Program 2 Operating System User Program 1 system call Read() Input Output begin Compute StartIO(input device) “System Software” Card WaitIO(interrupt) Tape Reader EndIO(input device) Operating System : 
 end Read Printer Tape Multiprogramming Multiprogramming (1965-1980) (1965-1980) Keep several jobs in memory and multiplex CPU between jobs Keep several jobs in memory and multiplex CPU between jobs Program 1 OS I/O Device Program 1 OS Program 2 I/O Device main{ main{ User Program n User Program n read{ read{ ... ... k : read() k : read() User Program 2 User Program 2 User Program 2 User Program 2 startIO() startIO() main{ schedule() waitIO() } User Program 1 User Program 1 endio{ endio() interrupt interrupt “System Software” “System Software” schedule() k +1: k +1: } } Operating System Operating System } }

History of Timesharing (1970-) Operating Systems Phase 1: Hardware is expensive, humans are cheap A timer interrupt is used to multiplex CPU between jobs User at console: single-user systems Program 1 OS Program 2 Batching systems Multi-programming systems main{ User Program n timer interrupt Phase 2: Hardware is cheap, humans are expensive schedule(){ k : ... Time sharing: Users use cheap terminals and share servers main{ User Program 2 User Program 2 } timer User Program 1 interrupt schedule(){ k +1: “System Software” } timer interrupt Operating System schedule(){ Operating Systems for History of PCs Operating Systems Personal computing systems Phase 1: Hardware is expensive, humans are cheap Single user User at console: single-user systems Utilization no longer a concern Batching systems Emphasis on user interface and API Multi-programming systems Many services & features not present Phase 2: Hardware is cheap, humans are expensive Time sharing: Users use cheap terminals and share servers Evolution Phase 3: Hardware is very cheap, humans are very expensive Initially: OS as a simple service provider (simple libraries) Personal computing: One system per user Distributed computing: many systems per user Now: Multi-application systems with Ubiquitous computing: LOTS of systems per users support for coordination

Why study Operating Systems? To learn how to manage complexity through appropriate abstractions infinite CPU, infinite memory, files, locks, etc. To learn about design performance vs. robustness, functionality vs. simplicity, HW vs. SW, etc. To learn how computers work Because OSs are everywhere! ! 21 Why study Operating Systems? To learn how to manage complexity through appropriate abstractions infinite CPU, infinite memory, files, locks, etc. To learn about design performance vs. robustness, functionality vs. simplicity, HW vs. SW, etc. Where’ s the OS? To learn how computers work Las Vegas Because OSs are everywhere!

Where’ s the OS? New York What kind of course? Top-down… Start from first principles What will the Re-derive the design of components of a complex system course be like? … & Bottom-up Dissect existing systems, to learn what tradeoffs they make what patterns they use

System Painting * building Order Reliability Design Availability Tension Portability Balance Efficiency Harmony Security System building is hard! * Sondheim: Sunday in the Park with George

Therac-25 Therac-25 [1982] Old system used a hardware interlock Computer-controlled radiation therapy machine Lever either in the “electron-beam” or “x-ray” position Safety critical system New system was computer controlled. with software interlocks A synchronization failure triggered when competent nurses prevent machine from used back arrow to change the data on the screen “too changing state because quickly” of state of another Engineers reused software from older models element it was buggy, but hardware interlocks masked the bugs Beam controlled entirely The system noted a problem and halted X-beam, displaying “MALFUNCTION” followed by obscure error code 54 through a custom OS technician resumed treatment Therac-25 Outcome System building is hard Patients received over 100x the recommended dose We do not have the necessary technologies and of radiation know-how to build robust computer systems Three patients died of radiation overdose The world is increasingly dependent on computer systems Many cancer patients received inadequate Connected, networked, interlinked treatment People died because a programmer could not write There is huge demand for people who deeply correct code for a concurrent system understand and can build robust systems (most people don’ t and can’ t) 37 Year Later…. Now what?

What’ s this course What makes a good OS? about? Ostensibly, operating systems The right set of abstractions Architecting complex software Identifying needs and priorities A good abstraction: Separating concerns is portable and hides implementation details Implementing artifacts with desired properties has an intuitive and easy-to-use interface In reality, software design principles can be installed many times OSes happen to illustrate organizational principles and design patterns is efficient and reasonably easy to implement This is a Capstone Course. Get Ready! OS: a collection of Issues in OS Design abstractions Structure: how is the OS organized? Concurrency: how are parallel activities created Processes (abstract CPU and RAM) and controlled? Files (abstract disks) Sharing: how are resources shared? Naming: how are resources named by users? Network endpoints (abstract NIC) Protection: how are distrusting parties protected Windows (abstract screens) from each other? … Security: how to authenticate, authorize, and ensure privacy? Think of them as objects with state and methods Performance: how to make it fast?

More Issues in OS Design Reliability: how do we deal with failures?? Portability: how to write once, run anywhere? Extensibility: how do we add new features? Communication: how do we exchange information? Scale: what happens as demands increase? Persistence: how do we make information outlast the processes that created it? Accounting: who pays the bill and how do we control resource usage?