Transcript Lecture 1 - Computer Science Department

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
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).
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.
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
Word
Processor
Compiler Shell
Editor
Application Software
Data Base
Systems Software
Operating System
Physical Network
Hardware
Machine Language
Micro Code
Physical Devices
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 ManagementFile system structure.
4. Security - File System, Network.
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?
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
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.
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.
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.
14.1 - 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)
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