OPERATING SYSTEMS. Goals of the Course. This lecture will cover: This Lecture will also cover:

Transcription

1 OPERATING SYSTEMS This lecture will cover: Goals of the course Definitions of operating systems Operating system goals What is not an operating system Computer architecture O/S services This Lecture will also cover: O/S resource management O/S achievement history Hardware architecture Processes Interrupts Goals of the Course This course is to provide a combined applied/ theoretical background in Operating Systems and Systems Programming to improve students understanding: 1. Systems software design 2. Systems programming 3. Performance analysis 4. Performance tuning 1

2 Some Prerequisites The Study of Operating Systems Relies on Many Areas: 1. Mathematics (a) Discrete Mathematics (b) Basic Calculus (c)probability (Exponential Distribution, Poisson Processes) Other Prerequisites 2. Computer Science (a) Computer Architecture (b) Programming Language Design (c) Software Design (d) Data Structures/ Algorithms Don t Panic if you are not familiar with all the topics, but it is best to be exposed to most of them. Operating System Definitions Operating System- a program that acts as an intermediary between a user of a computer and the computer hardware. Resource Allocator - manages and allocates resources. Control Program- controls the execution of user programs and operation of I/O devices. Kernel - the one program running at all times (all else being application programs). 2

3 O/S Design Goals An Operating System (O/S for short) provides the following: 1. A run time programming interface for applications. 2. Resource management. O/S Design goals include: 1. Convenience - Reduce Complexity for programmers/ users. 2. Efficiency - Allow efficient access to system resources. 3. Flexibility - Adding new features should be easy. What is not an O/S 1. Programming Language Compilers - Translators 2. Interpreter - Shell/ User Interface 3. Library - A set of commands/ utilities These features are typically provided as part of the O/S but are strictly speaking not the O/S. 3

4 Computer Architecture The following layers of abstraction are used (from highest to lowest): 1. Applications Software - Custom programs to support users. 2. Systems Software - Controls the hardware. 3. Hardware - The physical control of the system (signals). Web Browser Games Data Base Word Processor Compiler Shell Editor Operating System Physical Network Machine Language Micro Code Physical Devices Application Software Systems Software Hardware Figure 1: Computer Systems Architecture O/S Services Some O/S services for users are: 1. Program execution - Read program into memory/ run it return control when done. 2. Peripheral Access - I/O device driver interface. 3. Persistent Object Management- File system structure. 4. Security - File System, Network. 4

5 Other O/S Services 5. Error Detection/ Handling - Hardware failure, program errors. 6. Program Creation Tools - Debugging/ text editing etc. 7. Accounting - Billing for computer access O/S Resource Management O/S controls are intrusive because they both consume the resources which they seek to control and mediate conflicting requests. Resource Attributes Resources have properties governing their use including: 1. Preemption - How expensive is it for the device/ resource? 2. Renewability - Does the resource get replenished? 3. Scheduling - Does order of allocation matter? 4. Persistence - Does it s lifetime extend beyond that of the process which creates it? 5. Sharing - Is it suited to be accessed by many users? 5

6 Scheduling/ Allocation Policy The scheduled allocation of resources reflects policies including: 1. Fairness 2. Starvation Freedom 3. Maximum Throughput 4. Maximum Utilization 5. Minimize Response time. O/S Achievements Denning's list of conceptual breakthroughs (1980): Processes --- A program in execution Memory Management Information protection and security Scheduling and resource management System Structure A Traditional Hardware Architecture The traditional von Neumann structure consists of: 1) Processor - Also called the CPU (Central Processing Unit) our example has the registers: PC --- Program Counter IR --- Instruction Register MAR --- Memory Address Register MBR --- Memory Buffer Register I/O AR --- I/O Address Register I/O BR --- I/O Buffer Register 6

7 A Traditional Hardware Architecture (Continued) 2) Memory --- (Volatile) 3) Peripherals --- I/O Devices 4) Systems Interconnection --- Links the Other Components (Bus) Figure 2: von Neumann Architecture The register structure comes from Stallings; the names mean: 1) PC --- Program Counter --- Address of next instruction 2) IR --- Instruction Register --- Current OpCode to execute 3) MAR --- Memory Address Register --- Memory Pointer 4) MBR --- Memory Buffer Register --- Buffer for memory access 5) I/O AR --- I/O Address Register --- I/O Pointer 6) I/O BR --- I/O Buffer Register --- Buffer for I/O access User registers are not shown here. 7

8 Process Context The context of a process consists of: 1) The Current Instruction Pointer (the IP) 2) Register Contents 3) Memory used by that process This is the machine's current state used to determine the machines next state when running a particular program. The Model of Execution Traditionally called the fetch/ execute cycle, in its simplest form: (figure 3) Time- Sharing Systems- Interactive Computing The CPU is multiplexed among several jobs that are kept in memory and on disk (the CPU is allocated to a job only if the job is in memory). A job is swapped in and out of memory to the disk. On-line communication between the user and the system is provided; when the operating system finishes the execution of one command, it seeks the next control statement not from a card reader, but rather from the user s keyboard. On line file system must be available for users to access data and code. 8

9 Motivation for Interrupts An interrupt is an external asynchronous event changing the flow of control of a process (my definition). It is also refers to triggering such an event The Problem Peripherals tend to have slow response time (especially if waiting on human supplied input). The Solution To improve CPU utilization we want to allow the CPU to continue to execute while awaiting I/O as seen in Figure. When an interrupt is detected an interrupt handling routine is typically invoked. There are times (such as interrupt processing) where it may be desirable to disallow further interrupts. Interrupting the Fetch/Execute Cycle The fetch/ execute cycle is adjusted to support interrupts. (figure 4) 9

10 Interrupt Processing Processing an interrupt on most architectures involves the following steps: 1. Finish the current instruction 2. Push the IP on the stack 3. Set the IP to the interrupt handler's address. 4. Preserve the process context (i.e. push registers). 5. Executing the interrupt handling routine. 6. Restore the process context (i.e. pop registers). 7. Pop the IP from the stack 10