OPERATING SYSTEMS

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

2
This Lecture will also cover

• O/S resource management
• O/S achievement history
• Hardware architecture
• Processes
• Interrupts

3
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
4
Some Prerequisites

• The Study of Operating Systems Relies on Many
  Areas
• Mathematics
• (a) Discrete Mathematics
• (b) Basic Calculus
• (c)Probability (Exponential Distribution,
  Poisson
• Processes)

5
Other Prerequisites

• 2. Computer Science
• (a) Computer Architecture
• (b) Programming Language Design
• (c) Software Design
• (d) Data Structures/ Algorithms
• Dont Panic if you are not familiar
• with all the topics, but it is best to be
• exposed to most of them.

6
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).
7
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.
8
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.
9
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.
10
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).

11
Application Software
Systems Software
Hardware
Figure 1 Computer Systems Architecture
12
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.

13
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
14
O/S Resource Management
O/S controls are intrusive because they both
consume the resources which they seek to control
and mediate conflicting requests.
15
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 its lifetime extend beyond
that of the process which creates it? 5.
Sharing - Is it suited to be accessed by many
users?
16
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.
17
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
18
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
19
A Traditional Hardware Architecture (Continued)
2) Memory --- (Volatile) 3) Peripherals ---
I/O Devices 4) Systems Interconnection ---
Links the Other Components (Bus)
20
Figure 2 von Neumann Architecture
21
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.
22
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.
23
The Model of Execution
Traditionally called the fetch/ execute cycle, in
its simplest form (figure 3)
24

• 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 users keyboard.
• On line file system must be available for users
  to access data and code.

25
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).
26
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.
27
Interrupting the Fetch/Execute Cycle
The fetch/ execute cycle is adjusted to support
interrupts. (figure 4)
28
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