Transcript SG9OS

FIT1001- Computer Systems
Lecture 9
Introduction to Operating Systems
www.monash.edu.au
Lecture 9: Learning Objectives
•
•
•
•
•
•
explain the evolution of modern operating systems from early serial
and batch systems to present day - include basic operations of
each category and important developments;
discuss the important design factors and considerations involved
with operating system design;
define the terms process and thread;
discuss the four main services provided by the operating system;
process management, resource management (CPU, memory and
I/O), GUI and security / protection;
explain how processes and threads are structured and processed
by the CPU – includes process / thread states and scheduling
methods;
explain the key issues related to concurrency – includes deadlock,
mutual exclusion, race condition, starvation and critical section
(optional)
SG9: FIT1001 Computer Systems S1 2006
2
Introduction
www.monash.edu.au
Introduction
• Thomas J. Watson, Chairman of IBM 1949-1956
– “I think there is a world market for maybe five computers.”
• Over the preceding years since
– Numerous types of computers come and go
– Technological advancements
> Speed, complexity, size
– Market expanded beyond what Watson could dream of
• The biggest and fastest computer in the world is of
no use if it cannot efficiently provide beneficial
services to its users
– Users see the computer through their application programs
– These programs are ultimately executed by computer
hardware
SG9: FIT1001 Computer Systems S1 2006
4
Introduction
• Computer Organization (SG1)
– Each level providing an abstraction
for the layer below
– Today we are looking mainly at level 3
– Software at levels 3, 4 and 5 run
below application software and
just above the ISA
– Programs at these level work together
to grant access to hardware resources
that carry out the commands
• System software
– In the form of operating systems and middleware is the glue
that holds everything together
SG9: FIT1001 Computer Systems S1 2006
5
Evolution of Operating Systems
www.monash.edu.au
Evolution of Operating Systems
• The evolution of operating systems has paralleled
the evolution of computer hardware
– As hardware became more powerful, operating systems
allowed people to more easily manage the power of the
machine
• Modern operating systems can be traced back to
the era of mainframe computing
SG9: FIT1001 Computer Systems S1 2006
7
Evolution of Operating Systems
• Serial Processing
– Programmer interacted directly with the computer hardware
(no operating system)
– Programs in machine code were loaded in via input device
(usually a card reader)
– If an error occurred and halted the program
> Programmer checked processor registers and main memory to
determine error
– If no errors then output appeared on a printer
– Two main issues:
> Scheduling: users booked time in allotments
– Lead to wasted processing time / users not finished
> Setup times (software and hardware)
– If problems occurred the operator would have to start again
SG9: FIT1001 Computer Systems S1 2006
8
Evolution of Operating Systems
– Over time additions were added to make serial processing
more efficient
> Libraries of common functions, linkers, loaders, debuggers and
I/O driver routines
• Simple Batch Systems
– Early machines very expensive thus important to maximize
machine utilization
– First batch system appeared in the mid 1950s and by early
1960s a number of vendors had developed batch operating
systems
– Central idea was software called a “monitor”
> User had no direct access to hardware
> User submitted jobs (programs) on tape or card to an operator
– Places jobs in batch on input device for use by the monitor
SG9: FIT1001 Computer Systems S1 2006
9
Evolution of Operating Systems
– Each program is written to return to the monitor when it completes
processing
– At this point the monitor loads the next program
> Much of the Monitor resides in main memory (resident monitor)
– Other parts consisting of utilities and features loaded as subroutines
as requested by the incoming program being executed
> Function of the Monitor
– Monitor reads in jobs one at a time
– The current job is placed in the user program area (in memory)
– Control is passed to the job, when complete returns control to the
Monitor
> CPU function
– Encounters branch instructions from the Monitor to the start of the
job
– When complete (or error) control is returned to the Monitor
SG9: FIT1001 Computer Systems S1 2006
10
Evolution of Operating Systems
– JCL (Job Control Language)
> Special language to provide instructions to the Monitor
> Used to improve job setup time (load libraries, functions,
compliers etc required)
– Monitor relies on the ability of the processor to fetch
instructions from memory to seize and relinquish control
– Desired additional hardware features:
> Memory protection: running program must not attempt to alter
Monitor memory, processor should detect error and return
control to the Monitor
> Timer: used to prevent single jobs from using monopolizing the
system
> Privileged instructions: machine level instructions are privileged
and can be executed only by the Monitor
> Interrupts: provides the operating system more flexibility in
allocating and controlling jobs
SG9: FIT1001 Computer Systems S1 2006
11
Evolution of Operating Systems
• Multiprogrammed Batch Systems
– I/O devices are slow compared with the processor, hence
processor is often idle waiting for data to be transferred
– With simple batch system only the resident monitor and one
user program can be in main memory
> What if we can have two user programs?
> When one needs to wait for I/O the processor can switch to the
other job
> Can expand memory to hold three, four or any number of jobs
– Concept of multiprogramming / multitasking
SG9: FIT1001 Computer Systems S1 2006
12
Evolution of Operating Systems
– Example:
> A system has 250MB of memory (not used by operating
system), a disk, terminal (monitor) and printer
> Three jobs: 1, 2 and 3 submitted at the same time with various
attributes
> Assume minimal processor requirements for JOB2 and JOB3
> Assume continuous disk and printer use by JOB3
SG9: FIT1001 Computer Systems S1 2006
13
Evolution of Operating Systems
– Simple batch system
> The three jobs will be executed in sequence
– JOB1 will take 5 minutes
– JOB2 must wait the 5 minutes and completes 15 minutes after that
– JOB3 does not start for 20 minutes, and completes 30 minutes after
it was submitted
> So:
–
–
–
–
–
–
–
The processor use overall is 20%
Memory use is 33%
Disk use is 33%
Printer use is 33%
Elapsed time 30 minutes
Throughput is 6 jobs per hour
Mean response time is 18 minutes
SG9: FIT1001 Computer Systems S1 2006
14
Evolution of Operating Systems
– Multiprogramming batch system
> All three jobs are finished within 15 minutes
– There is little competition for resources
– JOB2 and JOB3 are provided with enough processor time to keep
their input and output operations active
– All three jobs can coexist and execute
– JOB1 will still require 5 minutes, but JOB2 will be one third finished
and JOB3 half finished
> So:
–
–
–
–
–
–
–
The processor use overall is 40%
Memory use is 67%
Disk use is 67%
Printer use is 67%
Elapsed time 15 minutes
Throughput is 12 jobs per hour
Mean response time is 10 minutes
SG9: FIT1001 Computer Systems S1 2006
15
Evolution of Operating Systems
SG9: FIT1001 Computer Systems S1 2006
16
Evolution of Operating Systems
– Multiprogramming batch system must rely on certain
hardware features
> Most notable is support for I/O interrupts and DMA (direct
memory access)
– With these features the processor can issue an I/O command for
one job an proceed with the execution of another
– I/O is carried out by the device controller until complete
– Multiprogramming operating systems
> Fairly sophisticated compare to single program systems
> Memory management required to keep several jobs in memory
> Scheduling algorithm used to decide execution of jobs
SG9: FIT1001 Computer Systems S1 2006
17
Evolution of Operating Systems
• Time sharing systems
– So far we have looked at executing multiple jobs, but what
about multiple users?
– Time sharing: processor is shared among multiple users
> Historically accessed via terminals but now is commonly
accessed via terminal emulators
> Allows multiple users to execute programs on a remote
systems, eg., UNIX / Linux systems
> The operating system allocates a small (but equal) amount of
processor time – a “quantum”, to each user program
> If we have n users they will only see 1/n of the computer
capacity
– On a properly designed system the performance should be similar
to that of a dedicated machine
– That is the user should not notice any major difference in the
performance of the system
SG9: FIT1001 Computer Systems S1 2006
18
Evolution of Operating Systems
– Example
> CTSS (Compatible Time Sharing System)
– Developed at MIT and introduced with the IBM 709 in 1961
– Eventually could support a maximum of 32 users
– Primitive compared to modern time sharing systems
> CTSS specs
–
–
–
–
–
32,000 words of main memory
Resident monitor using the first 5000
Remaining 27,000 words were allocated for user usage
A user’s program and data was always loaded into the 5000th word
A system clock generated an interrupt about every 0.2 seconds
» Allowed the operating system to regain control of the processor
» Allowed different users access the processor
– To save the previous user’s data for later resumption portions of the
data (or all the data) is written to disk before new programs and
data was loaded
SG9: FIT1001 Computer Systems S1 2006
19
Evolution of Operating Systems
– When the old user is allocated processor time again the saved data
is loaded back
– To avoid heavy disk traffic
» Memory was only saved when the incoming program would
overwrite it, so the portion of memory not written by the new
program was still held in memory
» This permitted quicker restore time for a previous user
» Of course if the new program was larger than the previous user
the system would save all the memory allocated the previous
user
> Consider 4 interactive user jobs with the following memory
requirements:
–
–
–
–
JOB1: 15,000
JOB2: 20,000
JOB3: 5000
JOB4: 10,000
SG9: FIT1001 Computer Systems S1 2006
20
Evolution of Operating Systems
SG9: FIT1001 Computer Systems S1 2006
21
Evolution of Operating Systems
• Other types of Modern Operating Systems
– Real time systems
> Operate within severe timing constraints
> If specific deadlines are not met this can lead to undesirable
effect, loss of function, property or even life
> Systems respond to external events so correct process
scheduling is critical
> Two categories
– Hard real-time: can have no errors (potentially fatal results can
occur if errors do occur)
– Soft real-time: meeting deadlines desirable but will not cause critical
results if missed
– Multiprocessor
> Systems have more than one processor
> How the operating system assigns processes to processors is a
major design consideration
SG9: FIT1001 Computer Systems S1 2006
22
Evolution of Operating Systems
> Generally the processors cooperate with each other to solve
problems
> Requires that the processors have some means of
communicating with each other
– This determines if the system is tightly or loosely coupled
multiprocessors
– Tightly coupled:
» Share a common memory and the same set of I/O devices
» Operating system must synchronize processes carefully to
assure protection
» Typically used on systems with 16 or less processors
» Symmetric multiprocessors (SMP) are an example
– Loosely coupled:
» have physically separate memory - often called distributed
systems
SG9: FIT1001 Computer Systems S1 2006
23
Evolution of Operating Systems
– Distributed/networked
> Distributed systems can be viewed in two different ways
– Collection of workstation on a LAN (local are network), each with its
own operating system
» Typically referred to as a networked system
» Multiple computers can share resources, allow remote access
and execution via the network operating system
» Can allow the use of one network file system (that is logical file
system) across the networked systems
» Can be geographically dispersed, have different architectures
and unrelated operating systems
» Synchronization and communications is critical
– Distributed operating system runs concurrently on all of the systems
» Presents one single machine view
» Transparency is the key – users should view and interact with
the system as one
SG9: FIT1001 Computer Systems S1 2006
24
Evolution of Operating Systems
– Scheduling is important in multiprocessor systems
> Multiple processors must be kept busy so poor scheduling will
inhibit the advantages of multiprocessor parallelism
• Operating Systems for Personal Computers
– Main goal was to make the operating system user friendly
– The idea that revolutionized small computer operating
systems was the BIOS (basic input-output operating system)
> A chip that permitted a single operating system to function on
different types of small systems
> The BIOS takes care of the details involved in addressing
divergent peripheral device designs and protocols
> Allowed the operating system to remain the same for various
machines, only the BIOS had to be altered
SG9: FIT1001 Computer Systems S1 2006
25
Evolution of Operating Systems
– Initially operating systems were:
> Single user / single tasking systems
– Examples include MS-DOS / Early Apple software
– Commands entered via keyboard, became known as command line
interfaces (CLI)
– Today we find:
> Multitasking systems
– Allowed multiple programs to be concurrently
– Adopted concepts from mainframe and minicomputers
– Graphical user interface (GUI) adopted (and the mouse)
» Initially created at Xerox PARC (was not invented by Apple or
Microsoft!)
» CLI were replaced with icons, windows and menus
> Multi-user systems
– Operating systems, such as Linux allow multi-user systems to be
installed on personal computer hardware – distinction blurring!
SG9: FIT1001 Computer Systems S1 2006
26
Operating System Design
www.monash.edu.au
Operating System Design
• Modern operating systems
– Much more complex than their earlier incarnations and
cousins
• Operating systems today
– May have similar interfaces / may perform tasks in a similar
manner
– Vary in their design and implementation
– No two operating systems are identical
> And no one operating system is superior in all respects
– Operating systems are event driven
> Performs tasks in response to an event
– Four main factors drive operating system design
> Performance / power / cost / compatibility
SG9: FIT1001 Computer Systems S1 2006
28
Operating System Design
• Design issue 1: Kernel architecture
– The kernel is the core of the operating system
– Responsible for scheduling, synchronization, protection /
security / memory management / dealing with interrupts
– Used by the process manager / the scheduler / resource
manager / I-O manager
– Has primary control over system hardware
– Loads all device drivers / provides common utilities /
coordinates all I/O activity
– Must know the specifics of the hardware
– Two types
> Microkernel and monolithic
SG9: FIT1001 Computer Systems S1 2006
29
Operating System Design
– Microkernel
> Provide rudimentary functionality - relying on other modules to
perform specific tasks
> Allows typical operating system services into the user space
– This allows many services to be restarted / reconfigured without
restarting the entire operating system
> Additional communications between the kernel and modules are
required – can cause slower and less efficient systems
> Key features
– Small size / easy portability / array of service run above the kernel
> Examples include Windows 2000 / XP, Mach and QNX
– Monolithic
>
>
>
>
Provide all essential functionally through a single process
Larger in size that microkernels
Interact directly with hardware so can be optimized more easily
Examples include Linux, MacOS and DOS
SG9: FIT1001 Computer Systems S1 2006
30
Operating System Design
• Design issue 2: Process / Thread Management
– The concept of process is fundamental to the structure of
operating systems
– Possible definitions of a process:
>
>
>
>
A program in execution
An instance of a program running on a computer
The entity the can be assigned to and executed on a processor
A unit of activity characterized by a single sequential thread of
execution, a current state, and an associated set of system
resources
– Three developments that contributed to the development of
the concept “process”
> Multiprogramming batch operation / time sharing / real time
transaction systems
> Problems with timing and synchronization
SG9: FIT1001 Computer Systems S1 2006
31
Operating System Design
– Principle tool in early multiprogramming and multi-user
systems was the interrupt
> Design of system software to coordinate interrupt activities was
difficult
> With many jobs it became impossible to analyze all the possible
combinations of sequence of events
> Without coordination and cooperation among activities
programmers applied an ad-hoc approach based on their
understanding of the environment
– Efforts caused subtle errors which only occurred with rare sequence
of actions
– Difficult to diagnose in terms of hardware or application software
errors
SG9: FIT1001 Computer Systems S1 2006
32
Operating System Design
> Four main causes of such errors:
–
–
–
–
Improper synchronization
Failed mutual exclusion
Nondeterminate program operation
Deadlocks
– Required
> Systematic approach to monitor and control various programs
executing on the processor
– Solution
> The concept of the process
> Consists of three parts
– An executable program
– The associated data needed by the program
– The execution context (process state) of the program
» Data used by operating system to supervise and control the
process, eg., contents of registers, priority of the process
» Other term is process control block (PCB)
SG9: FIT1001 Computer Systems S1 2006
33
Operating System Design
– Example
> Consider two processes
> Block of memory allocated to
each process
> Each process is recorded in a
process list maintained by
operating system
> Process index register points to
current process being executed
> PC points to next instruction in that
process to be executed
> Base / limit registers define the
region of memory
> PC and all data references must be
relative to the base register
(prevents interprocess interference)
SG9: FIT1001 Computer Systems S1 2006
34
Operating System Design
– A process can executing or waiting
– The entire state of the process at any instance is contained in
its context
> Context can contain:
–
–
–
–
–
–
A unique process identification number
Current state: executing or suspended
Events for which a process is waiting
Resources allocated
Ownership / access privileges
Scheduling priority / or data that priority can be determined
– Structure allows powerful techniques to be designed to
ensure coordination a cooperation among processes
> New features can be designed
> Incorporated into operating system by expanding context to
support the new feature(s)
SG9: FIT1001 Computer Systems S1 2006
35
Operating System Design
– Threads
> Smallest schedulable unit in a system
> Is part of a process (many threads can be associated to a
thread)
> Shares the same execution environment as the parent process
(including registers and page tables)
– Thread specific information stored in a thread control block (TCB)
» Each PCB contains sets of pointers to related TCBs
> Context switching (saving / loaded context) between threads
generates less overheads then switching entire process
– Therefore much faster that process switching
> Associated with the term multithreading
– A technique in which a process is divided into individual threads that
can run concurrently
– Threading is not automatic, programmer or compiler needs to
identify code segments that can execute independently
SG9: FIT1001 Computer Systems S1 2006
36
Operating System Design
• Design issue 3: Memory Management
– Operating system has five principle storage management
responsibilities:
>
>
>
>
>
Process isolation
Automatic allocation and management
Support for modular programming
Protection and access control
Long term storage
– Operating systems met these requirements by:
> File system facilities
– Implement long term storage with information stored as objects
(files)
– Useful unit of access control and protection
SG9: FIT1001 Computer Systems S1 2006
37
Operating System Design
> Virtual memory
– Provides additional main memory via hard disk
– Paging allows processes to be comprised of blocks (pages)
– Not all pages of a process need to be in main memory during
execution
– Paging and segmentation provides support for modular
programming
– Process isolation: giving a process a unique non overlapping
portion of virtual memory
– Memory sharing: provided by overlapping two virtual memory
spaces
– Designer
> Needs to develop an address translation mechanism that
generates little overhead
> Needs to develop storage allocation policy that minimizes the
traffic between memory levels
SG9: FIT1001 Computer Systems S1 2006
38
Operating System Design
• Design issue 4: Information Protection and Security
– Critical in today's environment
– Number of tools that can be included in operating system to
support variety of protection and security mechanisms
– Generally we are concerned about controlling access to
systems and the information on them
– Four general categories:
>
>
>
>
Availability – guards against interruption
Confidentiality – users cannot read from unauthorized areas
Data integrity – guards against unauthorized modification
Authenticity – correct verification of users / validity of messages /
data
SG9: FIT1001 Computer Systems S1 2006
39
Operating System Design
• Design issue 5: Scheduling and Resource Management
– Operating system must manage various resources
> Memory / processors / I-O devices etc)
– Operating system must schedule resources that may be in
use by various executing processes
– Three factors to consider:
> Fairness
> Differential responsiveness
> Efficiency
SG9: FIT1001 Computer Systems S1 2006
40
Operating System Design
– Development has focused on selecting the correct algorithms
and data structures that provides fairness, differential
responsiveness and efficiency
SG9: FIT1001 Computer Systems S1 2006
41
Operating System Design
• Design issue 6: System Structure
– It is fair to say that the complexity and size of operating
systems has grown
> Hardware: greater capability and versatility
> More features added to operating system to accommodate
requirements by users
> The UNIX, Linux or Windows of today is far different than earlier
incarnations
– Four common problems with current operating systems
> New versions and upgrades generally fall behind release date
> Latent bugs that show up after release (no matter how must
testing is done)
> Performance if often not what was expected
> Security issues
SG9: FIT1001 Computer Systems S1 2006
42
Operating System Design
– Recent focus to overcome problems is to focus on the
software structure
> Software must be modular
> Modules must have well defined interfaces to each other (and
must be simple)
– Modular approach not sufficient for operating systems with millions
lines of code
> Increasing use of the concepts of hierarchical layers /
information abstraction
– Separates functions according to:
» Their characteristic time scale
» Level of abstraction
– Each level performs a related subset of the function required of the
operating system
– Next lower level performs primitive functions / conceals the details
of these functions
SG9: FIT1001 Computer Systems S1 2006
43
Operating System Design
– Lower layers
generally deal with
shorter time scales
– The image to the left
is a depiction of these
principles
> Are applied
differently amongst
modern operating
systems
Grey = hardware
SG9: FIT1001 Computer Systems S1 2006
44
Operating System Services
www.monash.edu.au
Operating System Services
• We have seen in the last section a number of
critical design issues in relation to operating
systems design
– Discussed a number of critical services an operating system
must maintain
• In this section we will explore some of these, and
others, in view of what they do
SG9: FIT1001 Computer Systems S1 2006
46
Operating System Services
• The Human Interface
– Operating system provides a layer of abstraction between
user and the hardware
– Provides three interfaces (depending on view):
> Hardware developers: are interested in operating systems as an
interface to hardware
> Applications developers: operating systems is an interface to
application programs / services
> User interface (CLI / GUI)
SG9: FIT1001 Computer Systems S1 2006
47
Operating System Services
• Process Management
– Process management lies at the heart of operating system
services
> The operating system creates processes, schedules their
access to resources, deletes processes, and de-allocates
resources that were allocated during process execution
> The operating system monitors the activities of each process to
avoid synchronization problems that can occur when processes
use shared resources
> If processes need to communicate with one another the
operating system provides the services
– The operating system schedules process execution
> First, the operating system determines which process shall be
granted access to the processor
– This is long-term scheduling
SG9: FIT1001 Computer Systems S1 2006
48
Operating System Services
> Context switches occur when a process is taken from the
processor and replaced by another process
– Information relating to the state of the process is preserved during a
context switch
> Nest, after a number of processes have been admitted, the
operating system determines which one will have access to the
processor at any particular moment
– This is short-term scheduling
– Short-term scheduling can be nonpreemtive or premptive
» Nonpreemptive scheduling: a process has use of the processor
until either it terminates, or must wait for resources that are
temporarily unavailable / relinquishes the CPU voluntarily
» Preemptive scheduling: each process is allocated a time slice,
when the time slice expires a context switch occurs (commonly
via interrupts)
» A context switch can also occur when a higher-priority process
needs the CPU
SG9: FIT1001 Computer Systems S1 2006
49
Operating System Services
– Factors affecting scheduling:
> CPU utilization / throughput / turnaround time / waiting time /
response time
– Four approaches to short term scheduling are:
> First-come, first-served (FCFS): jobs are serviced in arrival
sequence and run to completion if they have all of the resources
they need
> Shortest job first (SJF): the smallest jobs get scheduled first
(The trouble is in knowing which jobs are shortest!)
> Round robin: each job is allotted a certain amount of CPU time,
a context switch occurs when the time expires.
> Priority scheduling: preempts a job with a lower priority when a
higher-priority job needs the processor
– Some operating systems offer a combination of scheduling
approaches
SG9: FIT1001 Computer Systems S1 2006
50
Operating System Services
– Example – Microsoft Windows Scheduling
> Operating systems support advanced features such as:
– Multitasking
– Multithreading
– Preemptive priority based scheduling and dispatch
> Each process is managed by the microkernel
> Each process is assigned a base priority level (integer 0-31)
– Four base priority classes
» Idle (0-6)
» Normal (6-10)
» High (11-15)
» Real-time (16-31)
> A process is assigned a base priority class when it is created
> Most user processes start in the Normal class
– Elevated to high by the kernel when moved from the background to
the foreground (eg., accepting input)
SG9: FIT1001 Computer Systems S1 2006
51
Operating System Services
> Threads inherit the base priority class of their parent process
> Thread priority classes are named:
–
–
–
–
–
–
–
Idle
Lowest
Below normal
Normal
Above normal
Highest
Time critical
> Current priority level of a thread is called its dynamic priority
– Initially the same as base priority of process
– Microkernel can alter dynamic priority to improve performance /
reflect demand (high or low) for a resource by a thread
SG9: FIT1001 Computer Systems S1 2006
52
Operating System Services
SG9: FIT1001 Computer Systems S1 2006
53
Operating System Services
Change priority of
Explorer to high
Priority of process
changes
Changes priority
of threads
SG9: FIT1001 Computer Systems S1 2006
54
Operating System Services
Can view modules
used by process
Change see
memory allocation
(eg ADVAPI32.dll)
SG9: FIT1001 Computer Systems S1 2006
55
Operating System Services
• Resource Management
– Three major resources
> Processor
> Memory
> I/O
– Access to the processor is controlled by the scheduler,
memory and I/O access requires different set of controls and
functions
– Before virtual memory
> Programmer implemented the overlay technique
– If the program was too large, the programmer divided it into pieces,
loading data and instructions necessary to run the program at that
time
– If new data and instructions needed it was up to the programmer
(and complier) to ensure correct pieces were in memory
SG9: FIT1001 Computer Systems S1 2006
56
Operating System Services
– Operating systems have now taken over that task
> Virtual memory extending RAM
– Virtual addresses / pages / page tables / segmentation etc
> Operating System determines
– Main memory allocation / tracks free frames
– Performs “garbage collection” – combines small portions of free
memory into larger chunks
> Processes share single finite memory
– Processes share I/O devices
> Operating system provides the required services to allow input
and output to occur
> Is possible for applications to do own I/O, but this duplicates
effort, presents protection and access issues
> Operating system mediates the call from several processes to
the same I/O device
SG9: FIT1001 Computer Systems S1 2006
57
Operating System Services
– Operating system provides a generic interface to I/O through
various system calls
– Calls allow an applications to request I/O service through the
operating system
– Operating systems then calls upon device drivers
» Device drivers: software that contains a standard set of
function relevant to the I/O device
– Operating system also control disk files
> Supports file creation and deletion / directory creation and
deletion / file and directory manipulation
> Mapping to secondary storage devices
SG9: FIT1001 Computer Systems S1 2006
58
Operating System Services
• Security and Protection
– Operating systems must also serve as a resource protector
> Operating system processes must be protected from user
processes
– Without it a user program could wipe a portion of the operating
system code, eg., part that deals with interrupts
> Concurrent processes must be protected from each other
– All active processes are allocated their own memory in which to
execute / operate in
– Requests for I/O or other resources pass through the operating
system
– Operating system executes commands in either user or kernel
modes to protect resources against unauthorized use
SG9: FIT1001 Computer Systems S1 2006
59
Operating System Services
> Multi-user systems need to protect both shared resources (eg.,
memory / I-O devices) and non-shared resources (eg., personal
files)
> Memory protection ensure a malfunctioning program is
contained and does not affect other running programs
> Operating systems also provide facilities to control user access
– Generally via login names and passwords
> Stronger access can be effected by restricting processes to a
single subsystem or partition
SG9: FIT1001 Computer Systems S1 2006
60
Protected Environments
www.monash.edu.au
Protected Environments
• In their role as resource managers and protectors,
many operating systems provide protected
environments that isolate processes, or groups of
processes from each other
• Three common approaches:
–
–
–
–
Virtual machines
Subsystems
partitions
These environments simplify system management and
control
– Can provide emulated machines to enable execution of
programs that the system would otherwise be unable to run
SG9: FIT1001 Computer Systems S1 2006
62
Protected Environments
• Virtual machines
– A protected environment that
presents an image of itself
– Can also present an image of a
totally different architecture
– A virtual machine is exactly an
imaginary computer (virtual)
– The underlying real machine is
under the control of the kernel
> The kernel receives and
manages all resource requests
that emit from processes
running in the virtual
environment
SG9: FIT1001 Computer Systems S1 2006
63
Protected Environments
– Eg., Java Virtual Machine (JVM) / Windows command prompt
/ VirtualPC / VMWare / WINE etc
– Of course virtual machines use virtual memory
> Must coexist with memory of the real operating system and
other running virtual machines
> Virtual machines can also use portions of the hard disk to store
itself
– Each virtual machine is generally regarded as a process and
is allocated main memory to run it
> This private address space is inaccessible by other processes
> Shared memory region can be allocated to allow data and
program code sharing among processes
SG9: FIT1001 Computer Systems S1 2006
64
Protected Environments
• Subsystems
– Provide logically distinct environments that can be individually
controlled and managed
– They can be stopped and started independently of each other
– Run on top of the operating system kernel
> Kernel provides access to fundamental system resources
– Subsystems can have special purposes
> Controlling I/O or virtual machines for example
> Others partition large application systems to make them more
manageable
– Assists management of large complex computer systems
> Each subsystem can be discretely controlled
> If a process goes out of control with a subsystem only that
subsystem is affected
SG9: FIT1001 Computer Systems S1 2006
65
Protected Environments
• Partitions
– In very large computers, subsystems do not go far enough to
establish a protected environment
– Logical partitions (LPARs) provide much higher barriers:
> Creates distinct machines within one physical system, with
nothing implicitly shared between them
> Processes running within a logical partition have no access to
processes running in another partition unless a connection
between them (e.g., FTP) is explicitly established
– LPARs are an enabling technology for the recent trend of
consolidating hundreds of small servers within the confines of
a single large system
SG9: FIT1001 Computer Systems S1 2006
66
Concurrency (Optional)
www.monash.edu.au
Concurrency
• The topic of concurrency is optional
• Students can read the referenced material if they
wish
– Material will not be examinable
SG9: FIT1001 Computer Systems S1 2006
68
Next Week
• Study Guide 10
– File Systems Features and Formats
SG9: FIT1001 Computer Systems S1 2006
69