Operating Systems

Download Report

Transcript Operating Systems

Course Info

Course Web page


Text Book


http://homer.csm.port.ac.uk/teaching/osarc/
Andrew S. Tanenbaum, Modern Operating Systems ,
2nd Ed (January 2001) Prentice Hall ISBN: 0130313580
Contact Info


Hong Ong - [email protected]
Garry Smith - [email protected]
OSAR Autumn 2001
1
What is an Operating System (OS)?

An OS is the interface between the user and the
hardware


An OS is the resource allocator



It implements a virtual machine that is easier to
program than bare hardware.
It manages and allocates resources such that the
computer hardware can be used in an efficient manner.
Examples of resources: processes, CPU(s), memory, file
system, networking, etc.
The goal in OS development is to make the
machine convenient to use and efficient.
OSAR Autumn 2001
2
Why study Operating Systems?

Most likely you won't write an OS, so why study
them?





Primary intersection point.
 It draws on many CS areas - software engineering, computer
architecture, data structures, networking, algorithms.
Can apply techniques (data structures, conflict resolution,
concurrency issues, resource management, etc.) used in OS to
other areas.
"Grungy" things sometimes do require modifications to OS
 you can't do this if you don't understand them!
Curiosity – “look under the hood”
“Operating systems are among the most complex pieces of
software yet developed”, William Stallings, 1994
OSAR Autumn 2001
3
Introduction - OS Overview





History of Operating Systems.
Operating System Components.
Computer Hardware Review.
Operating System Interface.
Operating System Structure.
OSAR Autumn 2001
4
History of Operating Systems.

Once upon a
time …

Human
Computer
OSAR Autumn 2001
5
History of Operating Systems

First
generation
1945 - 1955


(cont)
vacuum
tubes, plug
boards
ENIAC (mid1940’s)

Just part of
it!!
OSAR Autumn 2001
6
History of Operating Systems

Second generation 1955 - 1965


(cont)
transistors, batch systems
Early batch system (overlapped CPU & I/O operations)


Buffer slow I/O onto fast tape drives connected to CPU, replicate
I/O devices
Spool data to disk
OSAR Autumn 2001
7
History of Operating Systems

Third generation 1965
– 1980




(cont)
ICs and
multiprogramming
Multiple jobs are on
disk, waiting to run
Multi-programming –
run several programs
at the same time
IBM 360 series (mid1960s)
OSAR Autumn 2001
8
History of Operating Systems (cont)

Interactive timesharing

Lots of cheap terminals and one computer



Disks are cheap so put programs and data online


1 punch card = 100 bytes
New problems:




All users interact with the system at once
Debugging is much easier
Need pre-emptive scheduling to maintain adequate response
time
Need to avoid thrashing (swapping programs in and out of
memory too often)
Need to provide adequate security measures
UNIX developed at Bell Labs (Thompson, Ritchie)
OSAR Autumn 2001
9
History of Operating Systems (cont)


Fourth generation 1980 – present
Personal computing

CPUs are cheap enough for everyone, yet powerful
enough to be useful.
There can be only one…IBM PC
The only real competitor left…
vs.
IBM 8086
OSAR Autumn 2001
SUPERBOWL
10
More Recent Development in OS





Parallel Operating Systems.
Distributed Operating Systems.
Clustered Operating Systems.
Real time Operating Systems.
Embedded Operating Systems.
OSAR Autumn 2001
11
Parallel Operating Systems

Symmetric multiprocessing (SMP)




Each processor runs an identical copy of the operating
system.
Many processes can run at once without performance
deterioration.
Most modern operating systems support SMP
Asymmetric multiprocessing


Each processor is assigned a specific task; master
processor schedules and allocated work to slave
processors.
More common in extremely large systems
OSAR Autumn 2001
12
Distributed Operating Systems



Distribute the computation among several physical
processors.
Loosely coupled system – each processor has its own local
memory; processors communicate with one another
through various communications lines, such as high-speed
networks or telephone lines.
Advantages of distributed systems.







Resources Sharing
Computation speed up – load sharing
Reliability
Communications
Requires networking infrastructure.
Local area networks (LAN) or Wide area networks (WAN)
May be either client-server or peer-to-peer systems.
OSAR Autumn 2001
13
Clustered Operating Systems

Clustering allows two or more systems to share
storage.




Also known as SAN (Systems Area Network).
Provides high reliability.
Asymmetric clustering: one server runs the
application while other servers standby.
Symmetric clustering: all N hosts are running the
application
OSAR Autumn 2001
14
Real time Operating Systems


Often used as a control device in a dedicated
application such as controlling scientific
experiments, medical imaging systems, industrial
control systems, and some display systems.
Real-Time systems may be either hard or soft realtime.


Hard - Deadlines are urgent; “Everything” must be
bounded
Soft - Deadlines should be met, but if occasionally a
deadline can't be met, likely no one dies
OSAR Autumn 2001
15
Embedded Operating Systems


Personal Digital Assistants (PDAs)
Some Issues:



Limited memory
“Slow” processors
Small display screens.
OSAR Autumn 2001
16
OS’s: The Bad News...

Modern operating system are:

Enormous



Complex



Small OS = 100K lines of code
Big OS = 10M lines
Poorly understood – too large for one person to
comprehend.
(Always) full of bugs and (often) unreliable
Dependent on hardware in strange ways
(makes porting difficult)
OSAR Autumn 2001
17
OS Components
OSAR Autumn 2001
18
Hardware Components
Monitor
Bus

Components of a simple personal computer
OSAR Autumn 2001
19
CPU
(a) A three-stage pipeline
(b) A superscalar CPU
OSAR Autumn 2001
20
CPU Protection


Sharing system resources requires operating
system to ensure that an incorrect program cannot
cause other programs to execute incorrectly.
Provide hardware support to differentiate between
at least two modes of operations.


User mode – execution done on behalf of a user.
Monitor mode (also kernel mode or system mode) –
execution done on behalf of operating system.
OSAR Autumn 2001
21
CPU Protection (cont)


Mode bit added to computer hardware to indicate
the current mode: kernel (0) or user (1).
When an interrupt or fault occurs hardware
switches to kernel mode.
Interrupt/fault
kernel
user
set user mode
Privileged instructions can be issued only in monitor mode.
OSAR Autumn 2001
22
Memory Structure

Typical memory hierarchy

numbers shown are rough approximations
OSAR Autumn 2001
23
Cache



Use of high-speed memory to hold recentlyaccessed data.
Requires a cache management policy.
Caching introduces another level in storage
hierarchy. This requires data that is simultaneously
stored in more than one level to be consistent.
OSAR Autumn 2001
24
Memory

Volatile


Random Access Memory (RAM)
 Ranges from tens to hundreds of Megabytes,
 Program that can not fit into cache go to Memory.
Complementary Metal Oxide Semiconductor (CMOS)


For storing the current time and date, and system setup
parameters.
Non-Volatile



Write once
 Read only Memory (ROM)
Write many
 EEPROM (Electrically Erasable Programmable ROM)
 Flash RAM (special type of EEPROM);
 The difference is Flash RAM write in block.
Usually, use for storing BIOS (bootstrap loader)
OSAR Autumn 2001
25
Memory Protection
One base-limit pair and two base-limit pairs
OSAR Autumn 2001
26
I/O Devices






I/O devices and the CPU can execute either
synchronously or asynchronously.
Each device controller is in charge of a particular
device type.
Each device controller has a local buffer.
CPU moves data from/to main memory to/from
local buffers
I/O is from the device to local buffer of controller.
Device controller informs CPU that it has finished
its operation by causing an interrupt.
OSAR Autumn 2001
27
I/O Devices Protection


All I/O instructions are privileged instructions.
Must ensure that a user program could never gain
control of the computer in monitor mode (I.e., a
user program that, as part of its execution, stores
a new address in the interrupt vector).
OSAR Autumn 2001
28
OS Interfaces (Shell, API)




Command interpreter: Interface between OS and
your fingers (or mouth…or toes!)
Commands to manipulate files, run and kill
programs, access remote machines, change
protections on files, etc.
Some OS’s have “built-in” command interfaces,
some allow an interface to be “plugged in”
Unix: “shell” (csh, tcsh, bash, ash, zsh, …)
OSAR Autumn 2001
29
System calls - Programmer Interface




System calls are the programmer’s interface to the
operating system
In modern systems, generally available from a
high-level language such as C
Examples: fopen(), ioctl() (see MOS Fig 1.18 for
more systems calls)
Previously: Most of OS was written in assembly
and system calls were made from assembly
language
OSAR Autumn 2001
30
System Structure…Or Not?




Simplest system structure: little or none
Example: MS-DOS
Written to squeeze the most out of limited
hardware
Small, some structure, but programmer is free to
go around whatever structure is present anyway
OSAR Autumn 2001
31
UNIX (Traditional)

Two “layers”


Systems programs, user programs
monolithic (one big “blob” of code) kernel provides:





file system
scheduling
device management
etc.
Components are separated by “discipline” and
hacking requires care
OSAR Autumn 2001
32
Complications & Solutions, Cont.

Use microkernel approach instead:



Make kernel very small (provides only a limited amount
of the total OS functionality, like inter-process
communication & basic H/W control)
“Plug in” virtual memory system, file system, etc.
Gives encapsulation w/o strict layering
OSAR Autumn 2001
33
Virtual Machines


Virtual machine: fancy software which exports an
interface that looks like a particular type of
“machine”
Can create illusions of multiple computer systems,
which can be like the physical hardware or
completely different!
OSAR Autumn 2001
34
Popular Virtual Machine OS: VM
(IBM)





Each user on the machine can run an entirely
different OS
One application: Can debug OS while others are
working
Another application: Can work on custom OS
modifications without taking the system down
What’s more, VM can run VM!
Why?
OSAR Autumn 2001
35
Virtual Machines, Cont.

Sometimes a VM environment actually produces a
virtual machine that's faster than the real
thing…on the same hardware!



Example: VDM's under OS/2 (Virtual Dos Machines)
How can this be?
VM’s can be very difficult for OS’s like MS-DOS.
Why?
OSAR Autumn 2001
36
The Java Virtual Machine




Java achieves (relative) platform-independence
through the JVM (Java Virtual Machine)
JVM (java) is implemented for each target
platform
Java compiler (javac) emits bytecode (as *.class
files) rather than architecture-specific machine
code
JVM interprets the bytecode
OSAR Autumn 2001
37
The Java Virtual Machine, Cont.



Problem: Speed!
Java code typically executes more slowly than
“equivalent” C or C++ code
Solutions … (more like workaround!)
 JIT (Just In Time) compiler, which compiles the
bytecode into native machine code immediately
before execution
 AOT (Ahead of Time) compiler, which compiles
the bytecode into native machine code.
 Interesting issue: caching
OSAR Autumn 2001
38
Summary

A pseudo definition of OS:



A software program that acts as an intermediary
between a user or an application program of a
computer and the computer hardware
A brief history of OS.
A high-level of overview of OS

From top-down perspective,


From bottom-up perspective,


CPU, Memory, Disk, I/O and interrupt handling
Command interpreter and system calls.
From within,

Operating Systems structure.
OSAR Autumn 2001
39
For the rest of this semester …

Process Management


Memory Management



Paging, caching, swapping
I/O System Management


Threads, scheduling, mutual exclusion, deadlock , IPC,
etc.
File, Disk, Clock, device driver.
Protection and Security.
Intro to Distributed Systems.
OSAR Autumn 2001
40