Download Computing Systems Division

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Copland (operating system) wikipedia , lookup

Spring (operating system) wikipedia , lookup

RSTS/E wikipedia , lookup

Distributed operating system wikipedia , lookup

Unix security wikipedia , lookup

OS 2200 wikipedia , lookup

Process management (computing) wikipedia , lookup

Burroughs MCP wikipedia , lookup

System 7 wikipedia , lookup

VS/9 wikipedia , lookup

CP/M wikipedia , lookup

Transcript
CE01000-3 Operating Systems
Lecture 1
Introduction to the module, definition
and historical development of
operating systems
Who am I?


Martin Slade, room: K356 (top floor of the
Octagon), phone: 353554, e-mail:
[email protected]
Group Head for Computer Networks,
Architecture and Security Systems Group
Classes

2 lectures a week –



Monday 2pm & Tuesday 10am – both Green LT
usually one covering theory and the other giving a
practical illustration in Windows and Unix
2 hour tutorial/practical each week – in K104

go through theory questions and do some practical
exercises on example operating systems
(Windows & Linux)
Assessment


Class test – in last lecture of week 12 – worth
30% of marks
Portfolio of weekly tutorial and practical work
– worth 70% of marks
Portfolio coursework



Each week you will get some tutorial/practical
exercises to do.
The following week I will make available
answers to selected exercises
However, some of the tutorial and/or practical
exercises that you get will be specified as ones
which will be marked (and so there will be no
example answers)
Portfolio (continued)


On the Friday of week 12 (27th November)
you will have to submit the exercises that are
to be marked in a folder to the Faculty General
office as your coursework.
I will only tell you which of the weekly
exercises are the ones that will be marked the
week after the exercises have been set – so
you have a chance to do all the exercises.
Blackboard
PowerPoint of lecture slides, the tutorial &
practical exercises and example answers to the
selected exercises will be available on
Blackboard
http://Blackboard.staffs.ac.uk




Login using your user id. and password
Go to CE01000-3 Operating Systems and then
Course Documents
Also announcements, assessment information
and other general information
Operating Systems Reading

Operating systems theory – recommended
book:


Operating System Concepts, A. Silbershatz,
P. B. Galvin and G. Gagne, 8th edition,
Wiley, 2008
Most tutorial questions are taken from this
book

Windows – recommended book to read if you
are interested:


Microsoft Windows Internals, M.E.Russinovich
and D.A.Solomon, 4th edition, Microsoft Press,
2005
Linux – recommended book to read if
interested:

Operating Systems with Linux, J. O’Gorman,
Macmillan, 2001
Study time guide
Formally a module has a total of 150 hours
allocated to it as:
 48 hours lectures/tutorials/practicals
(including 1 hour for test in last lecture)
 leaving 102 hours left over which could be
organised by yourself as:
20 hours revision for the test
82 hours for work on tutorial/practical exercises
and weekly reading = almost 6 hours of
reading and independent study per week

Overview of rest of lecture
In the rest of this lecture we will be
looking at:
1. What is an operating system?  definition
and goals of operating systems
2. How did operating systems develop
historically to become what they are
today?  Outline of the historical
development of operating systems

Operating system - definition


An operating system is a program that
acts as an intermediary between a user
of a computer or developer of
application programs (and the
application programs themselves) and
the computer hardware.
Computer hardware + operating system
= usable machine
Goals of an operating system
To maximise utilisation of the hardware resources


sharing the hardware resources efficiently among different
user programs
To maximise the productivity of users



using the system by maximising the usability of the system
presenting an easy to use interface for managing data and
program execution
To provide a system call interface



for software developers to use
eliminating need for application programmers to write their
own software to manipulate hardware.



So operating systems are needed to make any
computer usable as a tool
The question is how did people come to
develop this large piece of software that we all
take for granted (until something goes wrong).
So where did everything start?

You need to refer to additional sheet on typical
sequence of operation of a computer at different
stages in OS development
Early Systems – Bare machine
(early 1950s)

Structure




Large machines (filling a room) run from a single
console or panel (often using wired plugs like old
fashioned telephone exchange)
Single user system - Programmer/User was the person
responsible for complete operation of machine
Paper tape or punched cards provide all I/O
Look at table in supplementary sheet to see
typical operation



Early Software - assemblers, compilers,
linkers, loaders + device drivers
Secure – no viruses/worms, hacking,
networks, etc
Inefficient use of very expensive resources (>
€100- €200 million at current money values)



Significant amount of setup time
Low CPU utilization (< 1% of time actually
running)
So need really to increase efficiency!!!!
Simple Batch Systems

Increase efficiency by:





Hiring an operator to run machine
User no longer had ANY direct contact with the
computer (everything done via submission of jobs to
operator who actually used the computer)
Reduce setup time by loading jobs together that have
similar requirements e.g. all jobs that need compiler
loaded together – known as batching (set of similar
jobs are a batch)
Use of resident monitor (see next slide)
Typical operation – see table in supplementary sheet
Resident monitor


Automatic job sequencing – automatically
transfer control from one job to another. This
lead to first rudimentary operating system
known as a resident monitor.
Resident monitor operation:



initial control in monitor
control transfers to loaded job to run
when job completes control transfers back to
monitor
Simple Batch Systems (Cont.)
Problems with simple batch systems:
1. How does the monitor know about the nature
of the job (e.g., Fortran compilation versus
Assembly) or which program to execute?
2. How does the monitor distinguish




(a) one job from another job?
(b) data from program?(Remember programs and
data just punched holes on cards or paper tape – so
how know?)
Solution - introduce control cards
Evolution of resident monitor

So resident monitor had to include:



Control card interpreter – responsible for reading and
carrying out instructions on the cards.
Loader – loads systems programs and applications
programs into memory.
Device drivers – know special characteristics and
properties for each of the system’s I/O devices and
input/output from/to devices e.g. card reader.
Monitor Problems

Problem with resident monitors:


Slow Performance – I/O and CPU could not overlap;
card reader very slow.
Solution:


Off-line operation (not connected to main computer) –
can speed up computation by loading jobs into
memory on-line from magnetic tapes rather than
directly from card readers
Card reading and line printing to/from magnetic tapes
then done off-line using small (much cheaper) satellite
processor/computer.
Batch with Off-Line Operation
Tape
Drives
Off-Line Operation (Cont.)



Advantage of off-line operation – main computer
not constrained by the speed of the card readers
and line printers, but only by the speed of much
faster magnetic tape units.
No changes need to be made to the application
programs to change from direct to off-line I/O
operation.
Real gain – possibility of using multiple reader-totape and tape-to-printer systems for one CPU.
Batch with Spooling



Spool = Simultaneous Peripheral Operation
On-Line
Spooling overlaps I/O of one job with
computation of another job while connected to
main computer by using a hard disk.
In spooling, the OS, while executing one job:


reads next job from card reader into a storage area
on the disk (job queue/pool) using an I/O channel.
outputs printout of previous job from disk (spool
area on disk) to printer via an I/O channel.



Job pool – is a data structure that allows the
OS to select which job to run next in order to
increase CPU utilization.
Spooling is a significant improvement over
off-line operation.
See table in supplementary sheet for typical
operation
Spooling
Multiprogrammed Batch Systems


Growth in size of main memory meant that job
pool and several jobs could all be held in main
memory. This lead to:
Multiprogramming = Several jobs are kept in
main memory at the same time, and the CPU is
multiplexed (switched) between them.

So that when one job is idle, rather than leaving
CPU idle, the OS can switch to running a different
job
OS Features Needed for
Multiprogramming
To provide multiprogramming facility OS now
needs to perform:
1. I/O – I/O now performed by the OS rather
than individual application program doing it
directly
2. Memory management – the system must
allocate the memory to several jobs and
prevent one job from interfering with memory
allocated to another.

3. CPU scheduling – the system must choose
which among several jobs to run (from those
that are ready to run)
4. Resource allocation of such things as I/O
devices to jobs.
 Operation of multiprogramming – see table on
supplementary sheet
Time-Sharing Systems –
Interactive Computing

Introduction of terminals with keyboards and
simple monochrome VDU displays meant that
users could now communicate directly with
running computer and not just indirectly via a
computer operator.
Time-Sharing Systems–
Interactive Computing (Cont.)

2 features of Time-sharing systems:
1.The CPU is multiprogrammed/multiplexed among
several jobs that are kept in memory and on disk jobs may be swapped to/from main memory and
disk (as before)
2. On-line communication between the user and the
system is provided (Interactive computing)

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.
Time-Sharing Systems–
Interactive Computing (Cont.)


Low turnaround time (quick response to user)
is desirable
Jobs (user programs and data) now need to be
on-line for user to be able to submit to system
to run i.e. there must now be an on-line file
system held on the disk.
Personal-Computer Systems



Come full circle in development -> personal
computers – computer system dedicated to a
single user (as were first computers)
I/O devices – keyboards, mice, display
screens, small printers, others (game
controllers, etc.).
User convenience and responsiveness is
primary goal, not efficient utilisation of
hardware
Sequence of operation of a computer
at different periods in OS evolution
Bare
machine
setup
Load program
Input – process – output
(cards)
(printer)
Tear down
Simple
batch
setup
Load program
Input – process – output
(cards)
(printer)
Input – process – output
(cards)
(printer)
Input – process – output
(cards)
(printer)
Tear down
Batch
setup
with OffLine
satellite
processor
s
Satellite
processor
Load program
(Mag. Tape)
Input – process – output
(Mag. Tape) (Mag Tape)
Input – process – output
(Mag. Tape) (Mag Tape)
Input – process – output
(Mag. Tape) (Mag Tape)
Tear down
Input from
cards to Mag
tape
Output from Mag tape to
printer
Batch
Bootup –
with
from disk
Spooling
–
Simultan
eous
Periphera
l
Operatio
n OnLine
Standard
Job 1 – Input – process–
programs
(disk)
permanently
Job 2 Input –
resident on
(disk)
disk.
Job 3
Jobs for
programs to do
submitted to
system from
cards to form
job pool
I/O Channel Input from
cards to Disk
Output from Disk to printer
output
(disk)
process – output
(disk)
Input – process – output
(disk)
(disk)
Computer operation and OS
evolution (continued)
Mutliprogrammed
“
Several jobs from job
pool on disk held in main
memory at the same time
Processor switches
between jobs when
current job needs to wait
for I/O from disk
Programs but
also much
data held
permamently
on disk (in
file system
on disk).
Jobs
submitted to
system from
terminal.
Input from
terminals as
well as cards,
etc,
Several jobs from job
pool on disk held in main
memory at the same
time.
Processor switches
between jobs when
current job needs to wait
for I/O from disk or
current job gets
interupted after a fixed
time quantum has
expired – to give
interactive users speedier
response
I/O
channel as
above
Interactive
(Time-shared)
and multiprogrammed
I/O
Channel
as before
Output to VDU screens
as well as printers
References


Operating System Concepts. Chapter 23.
Also see supplementary sheet summarizing
typical sequence of operation of computer at
different periods of operating systems
development