You are on page 1of 372

Principles of Operating Systems

Microlink Information Technology & Business College

Department of Computer Science

Principles of Operating Systems

Prepared By: Gebreslassie Etsay

Page 1
Principles of Operating Systems

Chapter one: Introduction to operating system


This chapter gives a basic idea about Operating System starting with definition of
operating system, and its functions .
 An operating System (OS) is an intermediary between users and computer hardware. It
provides users an environment in which a user can execute programs conveniently and
efficiently.
 In technical terms, it is software which manages hardware. An operating System controls
the allocation of resources and services such as memory, processors, devices and
information.
1.1 Definition of an operating system
 An operating system is a program that acts as an interface between the user and the
computer hardware and controls the execution of all kinds of programs.

 Following are some of important functions of an operating System.


 Memory Management
 Processor Management
 Device Management
 File Management
 Security
 Control over system performance

Page 2
Principles of Operating Systems

 Job accounting
 Error detecting aids
 Coordination between other software and users
Memory Manage ment
 Memory management refers to management of Primary Memory or Main Memory. Main
memory is a large array of words or bytes where each word or byte has its own address.
 Main memory provides a fast storage that can be access directly by the CPU. So for a
program to be executed, it must in the main memory. Operating System does the
following activities for memory management.
 Keeps tracks of primary memory i.e. what part of it are in use by whom, what
part are not in use.
 In multiprogramming, OS decides which process will get memory when and
how much.
 Allocates the memory when the process requests it to do so.
 De-allocates the memory when the process no longer needs it or has been
terminated.
Processor Manage ment
• In multiprogramming environment, OS decides which process gets the processor when
and how much time. This function is called process scheduling. Operating System does
the following activities for processor management.
 Keeps tracks of processor and status of process. Program responsible for this task
is known as traffic controller.
 Allocates the processor (CPU) to a process.
 De-allocates processor when processor is no longer required.
Device Management
 OS manages device communication via their respective drivers. Operating System does
the following activities for device management.
 Keeps tracks of all devices. Program responsible for this task is known as the I/O
controller.
 Decides which process gets the device when and for how much time.
 Allocates the device in the efficient way.
 De-allocates devices.

File Manage ment

Page 3
Principles of Operating Systems

 A file system is normally organized into directories for easy navigation and usage. These
directories may contain files and other directories. Operating System does the following
activities for file management.
 Keeps track of information, location, uses, status etc. The collective facilities are
often known as file system.
 Decides who gets the resources.
 Allocates the resources.
 De-allocates the resources.
Other Important Activities
 Following are some of the important activities that Operating System does.
 Security -- By means of password and similar other techniques, preventing
unauthorized access to programs and data.
 Control ove r system performance -- Recording delays between request for a
service and response from the system.
 Job accounting -- Keeping track of time and resources used by various jobs and
users.
 Error detecting aids -- Production of error messages and other debugging and
error detecting aids.
 Coordination between other software and users -- Coordination and
assignment of compilers, interpreters, assemblers and other software to the
various users of the computer systems.
1.2 History of operating systems

The 1940's - First Generations


 The earliest electronic digital computers had no operating systems.
 Machines of the time were so primitive that programs were often entered one bit at time
on rows of mechanical switches (plug boards).
 Programming languages were unknown (not even assembly languages).
 Operating systems were unheard of.
The 1950's - Second Generation
 By the early 1950's, the routine had improved somewhat with the introduction of punch
cards. The General Motors Research Laboratories implemented the first operating
systems in early 1950's for their IBM 701.
 The system of the 50's generally ran one job at a time.
The 1960's - Third Generation
 The systems of the 1960's were also batch processing systems, but they were able to take
better advantage of the computer's resources by running several jobs at once.

Page 4
Principles of Operating Systems

Fourth Gene ration


 With the development of LSI (Large Scale Integration) circuits, chips, operating system
entered in the personal computer and the workstation age.
 Microprocessor technology evolved to the point that it becomes possible to build desktop
computers as powerful as the mainframes of the 1970s.

1.3 Types of operating system


Operating systems are there from the very first computer generation. Operating systems
keep evolving over the period of time. Following are few of the important types of operating
system which are most commonly used.
Batch operating system
 An operating system is a program that acts as an interface between the user and the
computer hardware and controls the execution of all kinds of programs.
 The users of batch operating system do not interact with the computer directly. Each user
prepares his job on an off- line device like punch cards and submits it to the computer
operator. To speed up processing, jobs with similar needs are batched together and run as
a group. Thus, the programmers left their programs with the operator. The operator then
sorts programs into batches with similar requirements.
 The problems with Batch Systems are following.
 Lack of interaction between the user and job.
 CPU is often idle, because the speeds of the mechanical I/O devices are slower
than CPU.
 Difficult to provide the desired priority.
Time-sharing ope rating systems
 Time sharing is a technique which enables many people, located at various terminals, to
use a particular computer system at the same time.
 Time-sharing or multitasking is a logical extension of multiprogramming. Processor's
time which is shared among multiple users simultaneously is termed as time-sharing.
 The main difference between Multiprogrammed Batch Systems and Time-Sharing
Systems is that in case of multiprogrammed batch systems, objective is to maximize
processor use, whereas in Time-Sharing Systems objective is to minimize response time.
 Multiple jobs are executed by the CPU by switching between them, but the switches
occur so frequently. Thus, the user can receive an immediate response. For example, in a
transaction processing, processor execute each user program in a short burst or quantum
of computation. That is if n users are present, each user can get time quantum. When the
user submits the command, the response time is in few seconds at most.
 Operating system uses CPU scheduling and multiprogramming to provide each user with
a small portion of a time. Computer systems that were designed primarily as batch
systems have been modified to time-sharing systems.
Advantages and Disadvantages of Timesharing OS

Page 5
Principles of Operating Systems

 Advantages
 Provide advantage of quick response.
 Avoids duplication of software.
 Reduces CPU idle time.
 Disadvantages
 Problem of reliability.
 Question of security and integrity of user programs and data.
 Problem of data communication.

Distributed operating System


 Distributed systems use multiple central processors to serve multiple real time application
and multiple users. Data processing jobs are distributed among the processors
accordingly to which one can perform each job most efficiently.
 The processors communicate with one another through various communication lines
(such as high-speed buses or telephone lines). These are referred as loosely coupled
systems or distributed systems. Processors in a distributed system may vary in size and
function. These processors are referred as sites, nodes, and computers and so on.
 The advantages of distributed systems are following.
 With resource sharing facility user at one site may be able to use the resources available
at another.
 Speedup the exchange of data with one another via electronic mail.
 If one site fails in a distributed system, the remaining sites can potentially continue
operating.
 Better service to the customers.
 Reduction of the load on the host computer.
 Reduction of delays in data processing.
Network operating System (NOS)
 Network Operating System runs on a server and and provides server the capability to
manage data, users, groups, security, applications, and other networking functions.
 The primary purpose of the network operating system is to allow shared file and printer
access among multiple computers in a network, typically a local are a network (LAN), a
private network or to other networks.
 Examples of network operating systems are Microsoft Windows Server 2003, Microsoft
Windows Server 2008, UNIX, Linux, Mac OS X, . . .
Advantages of NOS
 Centralized servers are highly stable.

Page 6
Principles of Operating Systems

 Security is server managed.


 Upgrades to new technologies and hardware can be easily integrated into the
system.
 Remote access to servers is possible from different locations and types of
systems.
Disadvantages of NOS
 High cost of buying and running a server.
 Dependency on a central location for most operations.
 Regular maintenance and updates are required.
Real Time operating System
 Real time system is defines as a data processing system in which the time interval
required to process and respond to inputs is so small that it controls the environment.
 Real time processing is always on line whereas on line system need not be real time. The
time taken by the system to respond to an input and display of required updated
information is termed as response time.
 So in this method response time is very less as compared to the online processing.
 Real-time systems are used when there are rigid time requirements on the operation of a
processor or the flow of data and real-time systems can be used as a control device in a
dedicated application. Real- time operating system has well-defined, fixed time
constraints otherwise system will fail.
 For example Scientific experiments, medical imaging systems, industrial control systems,
weapon systems, robots, and home-appliance controllers, Air traffic control system etc.
There are two types of real -time operating systems.
Hard real-time systems
Hard real-time systems guarantee that critical tasks complete on time. In hard real -time systems
secondary storage is limited or missing with data stored in ROM. In these systems
virtual memory is almost never found.
Soft real-time systems
Soft real time systems are less restrictive. Critical real-time task gets priority over other tasks and
retains the priority until it completes. Soft real-time systems have limited utility than hard real
time systems. For example, Multimedia, virtual reality, Advanced Scientific Projects like
undersea exploration and planetary rovers etc.

1.4 Operating system services


 An Operating System provides services to both the users and to the programs.
 It provides programs, an environment to execute.
 It provides users, services to execute the programs in a convenient manner.

Page 7
Principles of Operating Systems

 Following are few common services provided by operating systems.


1. Program execution 2. I/O operations 3. File System manipulation
4. Communication 5. Error Detection 6. Resource Allocation 7.Protection
Program Execution
 Operating system handles many kinds of activities from user programs to system
programs like printer spooler, name servers, file server etc. Each of these activities is
encapsulated as a process.
 A process includes the complete execution context (code to execute, data to manipulate,
registers, OS resources in use). Following are the major activities of an operating system
with respect to program management.
 Loads a program into memory.
 Executes the program.
 Handles program's execution.
 Provides a mechanism for process synchronization.
 Provides a mechanism for process communication.
 Provides a mechanism for deadlock handling.
I/O Operation
 I/O subsystem comprised of I/O devices and their corresponding driver software. Drivers
hides the peculiarities of specific hardware devices from the user as the device driver
knows the peculiarities of the specific device.
 Operating System manages the communication between user and device drivers.
Following are the major activities of an operating system with respect to I/O Operation.
 I/O operation means read or write operation with any file or any specific I/O
device.
 Program may require any I/O device while running.
 Operating system provides the access to the required I/O device when required.
File system manipulation
 A file represents a collection of related information. Computer can store files on the disk
(secondary storage), for long term storage purpose. Few examples of storage media are
magnetic tape, magnetic disk and optical disk drives like CD, DVD. Each of these media
has its own properties like speed, capacity, data transfer rate and data access methods.
 A file system is normally organized into directories for easy navigation and usage. These
directories may contain files and other directions. Following are the major activities of an
operating system with respect to file management.
 Program needs to read a file or write a file.
 The operating system gives the permission to the program for operation on file.

Page 8
Principles of Operating Systems

 Permission varies from read-only, read-write, denied and so on.


 Operating System provides an interface to the user to create/delete files.
 Operating System provides an interface to the user to create/delete directories.
 Operating System provides an interface to create the backup of file system.
Communication
 In case of distributed systems which are a collection of processors that do not share
memory, peripheral devices, or a clock, operating system manages communications
between processes. Multiple processes with one another through communication lines in
the network.
 OS handles routing and connection strategies, and the problems of contention and
security. Following are the major activities of an operating system with respect to
communication.
 Two processes often require data to be transferred between them.
 Both processes can be on the one computer or on different computer but are
connected through computer network.
 Communication may be implemented by two methods either by Shared Memory
or by Message Passing.
Error handling
 Error can occur anytime and anywhere. Error may occur in CPU, in I/O devices or in the
memory hardware. Following are the major activities of an operating system with respect
to error handling.
 OS constantly remains aware of possible errors.
 OS takes the appropriate action to ensure correct and consistent computing.
Resource Management
 In case of multi- user or multi- tasking environment, resources such as main memory, CPU
cycles and files storage are to be allocated to each user or job. Following are the major
activities of an operating system with respect to resource management.
 OS manages all kind of resources using schedulers.
 CPU scheduling algorithms are used for better utilization of CPU.
Protection
 Considering computer systems having multiple users the concurrent execution of multiple
processes, then the various processes must be protected from each another's activities.
 Protection refers to mechanism or a way to control the access of programs, processes, or
users to the resources defined by computer systems. Following are the major activities of
an operating system with respect to protection.
 OS ensures that all access to system resources is controlled.

Page 9
Principles of Operating Systems

 OS ensures that external I/O devices are protected from invalid access attempts.
 OS provides authentication feature for each user by means of a password.

1.5 Operating system properties


This section discusses various properties of an Operating System.
 Following are few of very important tasks that Operating System handles
 Batch processing
 Multitasking
 Multiprogramming
 Spooling

Batch Processing
 Batch processing is a technique in which Operating System collects one programs and
data together in a batch before processing starts. Operating system does the following
activities related to batch processing.

 OS defines a job which has predefined sequence of commands, programs and data
as a single unit.
 OS keeps a number a jobs in memory and executes them without any manual
information.
 Jobs are processed in the order of submission i.e. first come first served fashion.
 When job completes its execution, its memory is released and the output for the
job gets copied into an output spool for later printing or processing.

Advantages

 Batch processing takes much of the work of the operator to the compute
 Increased performance as a new job gets started as soon as the previous job
finished without any manual intervention.

Page 10
Principles of Operating Systems

Disadvantages

Page 11
Principles of Operating Systems

 Difficult to debug program.


 A job could enter an infinite loop.
 Due to lack of protection scheme, one batch job can affect pending jobs.
Multitasking
 Multitasking refers to term where multiple jobs are executed by the CPU simultaneously
by switching between them. Switches occur so frequently that the users may interact with
each program while it is running. Operating system does the following activities related
to multitasking.
 The user gives instructions to the operating system or to a program directly, and
receives an immediate response.
 Operating System handles multitasking in the way that it can handle multiple
operations / executes multiple programs at a time.
 Multitasking Operating Systems are also known as Time-sharing systems.
 These Operating Systems were developed to provide interactive use of a computer
system at a reasonable cost.
 A time-shared operating system uses concept of CPU scheduling and
multiprogramming to provide each user with a small portion of a time-shared
CPU.
 Each user has at least one separate program in memory.

 A program that is loaded into memory and is executing is commonly referred to


as a process.
 When a process executes, it typically executes for only a very short time before it
either finishes or needs to perform I/O.

Page 12
Principles of Operating Systems

 Since interactive I/O typically runs at people speeds, it may take a long time to complete.
During this time a CPU can be utilized by another process.
 Operating system allows the users to share the computer simultaneously. Since each
action or command in a time-shared system tends to be short, only a little CPU time is
needed for each user.
 As the system switches CPU rapidly from one user/program to the next, each user is
given the impression that he/she has his/her own CPU, whereas actually one CPU is
being shared among many users.
 When two or more programs are residing in memory at the same time, then sharing the
processor is referred to the multiprogramming. Multiprogramming assumes a single
shared processor. Multiprogramming increases CPU utilization by organizing jobs so that
the CPU always has one to execute.
 Operating system does the following activities related to multiprogramming.
 The operating system keeps several jobs in memory at a time.
 This set of jobs is a subset of the jobs kept in the job pool.
 The operating system picks and begins to execute one of the job in the memory.
 Multiprogramming operating system monitors the state of all active programs and system
resources using memory management programs to ensures that the CPU is never idle
unless there are no jobs.
 Advantages
 High and efficient CPU utilization.
 User feels that many programs are allotted CPU almost simultaneously.
 Disadvantages
 CPU scheduling is required.
 To accommodate many jobs in memory, memory management is required.
Spooling
 Spooling is an acronym for simultaneous peripheral operations on line. Spooling refers to
putting data of various I/O jobs in a buffer. This buffer is a special area in memory or
hard disk which is accessible to I/O devices. Operating system does the following
activities related to distributed environment.
 OS handles I/O device data spooling as devices have different data access rates.
 OS maintains the spooling buffer which provides a waiting station where data can rest
while the slower device catches up.
 OS maintains parallel computation because of spooling process as a computer can
perform I/O in parallel fashion. It becomes possible to have the computer read data from
a tape, write data to disk and to write out to a tape printer while it is doing its computing
task.

Page 13
Principles of Operating Systems

Advantages
 The spooling operation uses a disk as a very large buffer.
 Spooling is capable of overlapping I/O operation for one job with processor operations
for another job.

Page 14
Microlink Information and
Business College-Mekelle

Principles of Operating Systems

Prepared by:G/slassie E.
CHAPTER TWO

PROCESSES AND PROCESS MANAGEMENT


Outline

2.1 The Process Concept


2.2 Process Scheduling
2.3 The Threads concept
2.4 Inter-process Communication
2.5 Deadlocks
Chapter Two: part 2.1- The process concepts
outline
 The process concept
 Process life cycle/Process states/
 process control block(PCB)
 Process creation and termination
The Process Concept
 An operating system executes a variety of
programs
 batch systems - jobs
 time-shared systems - user programs or tasks
 job and program used interchangeably
 Process - a program in execution
 process execution proceeds in a sequential fashion
 A process contains
 program counter, stack and data section
Process =? Program
Program :-
 Is a piece of code which may be a single line or
millions of lines.
Process :-
 is defined as an entity which represents the basic
unit of work to be implemented in the system.
 When a program is loaded into the memory and it
becomes a process.
 To put it in simple terms , we write our computer
programs in a text file and when we execute this
program , it becomes a process.
Process life cycle
 Also known as process states. When a process
executes , it passes through different states .in
general, a process can have one of the following
five stages at a time.
new admitted
exit terminated

interrupt

ready running

Scheduler
I/O or dispatch I/O or
event
completion event wait

waiting
Process States

 New - The process is being created.


 Running - Instructions are being executed.
 Waiting - Waiting for some event to occur.
 Ready - Waiting to be assigned to a
processor.
 Terminated - Process has finished execution.
Process Control Block
 Is a data structure maintained by the
operating system for every process.
 Contains information associated with
each process
 Process State – the current state of the
process i.e., whether it is new, ready,
running etc.
 Process Number – Process ID
 Program Counter –a pointer to the address
of next instruction to be executed
 CPU registers – various CPU registers
where process need to be stored for
execution for running state.
 CPU scheduling information - process
priority and other scheduling Info, pointer Process
 Memory Management information – this Control
inculdes the information of page
table,memory limits etc Block
 Accounting information - time limits,
process number
Process Creation

 Processes are created and deleted


dynamically
 Process which creates another process is
called a parent process; the created process
is called a child process.
 Result is a tree of processes
 e.g. UNIX - processes have dependencies and form a
hierarchy.
 Resources required when creating process
 CPU time, files, memory, I/O devices etc.
UNIX Process Hierarchy
What does it take to create a process?

 Must construct new PCB


 Inexpensive
 Must set up new page tables for address space
 More expensive
 Copy data from parent process? (Unix fork() )
 Semantics of Unix fork() are that the child process gets a
complete copy of the parent memory and I/O state
 Originally very expensive
 Much less expensive with “copy on write”
 Copy I/O state (file handles, etc)
 Medium expense
Process Termination

 Process executes last statement and asks


the operating system to delete it (exit).
 Output data from child to parent (via wait).
 Process’ resources are deallocated by operating system.
 Parent may terminate execution of child
processes.
 Child has exceeded allocated resources.
 Task assigned to child is no longer required.
 Parent is exiting
 OS does not allow child to continue if parent terminates
 Cascading termination
Principles of
Operating Systems

Chapter Two:
Part 2: process scheduling

1
Outline
Introduction to process scheduling
Process scheduling queues
Levels of Scheduling
Scheduling Criteria
Scheduling Algorithms
FCFS, Shortest Job First, Priority, Round Robin, Multilevel
Multiple Processor Scheduling
Real-time Scheduling
Algorithm Evaluation
2
2.2 Process Scheduling
The process scheduling is the activity of the
process manager that handles the removal of
the running process from the CPU and the
selection of another process on the basis of a
particular strategy.
Process scheduling is essential for operating
systems that allow more than one process to be
loaded into the executable memory at a time
and the loaded process shares the CPU using
time multiplexing.

3
Process Scheduling…
As we know that we can perform many
Programs at a Time on the Computer. But there
is a Single CPU. So, for running all the Programs
concurrently or simultaneously, Then we use the
Scheduling.
CPU Executes all the Process according to Some
Rules or Some Schedule. Scheduling is that in
which each process have Some Amount of Time
of CPU.
Scheduling Provides Time of CPU to each
Process.

4
Process Scheduling Queues
The OS maintains the following important process
scheduling queues. Process migration between the
various queues.
Job Queue – This queue keeps set of all
processes in the system
Ready Queue - This queue keeps set of all
processes residing in main memory, ready and
waiting to execute.
Device Queues - This queue keeps set of
processes waiting for an I/O device.

5
Context Switch
Is the mechanism to store and restore the state
or context of a CPU in PCB so that a process
execution can be resumed from the same point
at a later time.
Task that switches CPU from one process to
another process
• the CPU must save the PCB state of the old process and load
the saved PCB state of the new process.

Context-switch time is overhead


• System does no useful work while switching
• Overhead sets minimum practical switching time; can become
a bottleneck

Time for context switch is dependent on


hardware support ( 1- 1000 microseconds).
6
Process/Program/ Behavior
Issues

I/O bound process -


• spends more time in I/O, short CPU bursts, CPU underutilized.

CPU bound process -


• spends more time doing computations; few very long CPU
bursts, I/O underutilized.

The right job mix:


• Long term scheduler - admits jobs to keep load balanced
between I/O and CPU bound processes
• Medium term scheduler – ensures the right mix (by sometimes
swapping out jobs and resuming them later)

7
Levels of Scheduling:
HIGH LEVEL: Scheduling of a complete set of
resources for a job or session. Determines
admission to the system. Also called long-term
scheduling, job scheduling.
INTERMEDIATE LEVEL: Scheduling of main
memory, primarily in a timesharing
environment. Also called medium-term
scheduling, storage scheduling.
LOW LEVEL: Scheduling of the processor or
processors, necessary for any system type. Also
called short-term scheduling, processor
scheduling, CPU scheduling.
8
Levels of Scheduling(cont.)

9
Schedulers
Scheduler are special system software which handles process
scheduling in various ways. Their main task is to select the jobs to be
submitted into the system and to decide which process to run.
Schedulers are of threeTypes :-
Long-term scheduler (or job scheduler) -
• selects which processes should be brought into the ready
queue.
• invoked very infrequently (seconds, minutes); may be slow.
• controls the degree of multiprogramming
Short term scheduler (or CPU scheduler) -
• selects which process should execute next and allocates CPU.
• it is the change of ready state to running state of the process .
• invoked very frequently (milliseconds) - must be very fast
• Also known as dispatchers , make the decision of which
process to execute next.
Medium Term Scheduler
• Is in charge of handling swaps out process temporarily
• Is parts of swapping.it removes the processes from the
memory. 10
CPU Scheduler

Selects from among the processes in memory


that are ready to execute, and allocates the CPU
to one of them. There are Two Types of
Scheduling
Non-preemptive Scheduling:-means No scheduling
then all the Jobs are Executed One by One.
Once CPU has been allocated to a process, the process
keeps the CPU until
Preemptive Scheduling:-In this all the Processes are
executed by using some Amount of Time of CPU.
Process can be interrupted and must release the CPU.
• Switching context 11
CPU Scheduling Decisions

CPU scheduling decisions may take place when


a process:
• switches from running state to waiting state
• switches from running state to ready state
• switches from waiting to ready
• terminates

Scheduling under 1 and 4 is non-preemptive.


All other scheduling is preemptive.

12
CPU scheduling decisions

new admitted
exit terminated

interrupt

ready running

Scheduler
I/O or dispatch I/O or
event
completion event wait

waiting

13
Scheduling Criteria

Waiting time
amount of time a process has been waiting in the ready
queue.
CPU Utilization
Keep the CPU and other resources as busy as possible
Throughput
number of processes that complete their execution per time
unit.
Turnaround time
amount of time to execute a particular process from its
entry time. i.e. The interval from time of submission of the
process to the time of completion of the process 14
Scheduling Criteria (cont.)

Response Time (in a time-sharing environment)


amount of time it takes from when a request was submitted
until the first response is produced, NOT output.

15
Optimization Criteria

Max CPU Utilization


Max Throughput
Min Turnaround time
Min Waiting time
Min response time

16
scheduling Algorithms

We'll discuss five major scheduling algorithms


here which are following :
First Come First Serve(FCFS) Scheduling
Shortest-Job-First(SJF) Scheduling
Priority Scheduling
Round Robin(RR) Scheduling
Multilevel Queue Scheduling

17
1.First Come First Serve
(FCFS) Scheduling
Policy: Process that requests the CPU FIRST is
allocated the CPU FIRST.
FCFS is a non-preemptive algorithm.
Implementation - using FIFO queues
• incoming process is added to the tail of the queue.
• Process selected for execution is taken from head of queue.

Performance metric - Poor in performance as


average wait time is high.
Easy to understand and implement.
Gantt Charts are used to visualize schedules.
It is a non-preemptive,preemptive scheduling
algoriithms. 18
FCFS Scheduling…

 Example  Suppose the arrival order


Process Burst Time for the processes is
P1 24 P1, P2, P3
P2 3
P3 3  Waiting time
P1 = 0;
P2 = 24;
Gantt Chart for Schedule
P3 = 27;
 Average waiting time
P1 P2 P3

0 24 27 30 (0+24+27)/3 = 17

19
FCFS Scheduling …

 Example  Suppose the arrival order


Process Burst Time
for the processes is
P1 24 P2, P3, P1
P2
P3
3
3
 Waiting time
P1 = 6; P2 = 0; P3 = 3;

Gantt Chart for Schedule  Average waiting time


(6+0+3)/3 = 3 , better..
P2 P3 P1
 Convoy Effect:
0 3 6 30 • short process behind
long process, e.g. 1 CPU
bound process, many
I/O bound processes.

20
2.Shortest-Job-First(SJF)
Scheduling

In shortest job first scheduling, the shortest


process executed first.
Best approach to minimize waiting time.
Actual time taken by the process is already
known to processor.
It is a non-preemptive,preemptive scheduling
algoriithms.

21
SJF Scheduling…

Associate with each process the length of its next


CPU burst. Use these lengths to schedule the process
with the shortest time.
Two Schemes:
Scheme 1: Non-preemptive
• Once CPU is given to the process it cannot be preempted until
it completes its CPU burst.
Scheme 2: Preemptive
• If a new CPU process arrives with CPU burst length less than
remaining time of current executing process, preempt. Also
called Shortest-Remaining-Time-First (SRTF).
SJF is optimal - gives minimum average waiting time for a
given set of processes.
22
SJF Scheduling…

23
Non-Preemptive SJF
Scheduling

24
Non-Preemptive SJF
Scheduling…

Example 2:
Process Arrival Time Burst Time
P1 0 7
P2 0.2 4
P3 4 1
P4 5 4
Gantt Chart for Schedule

P1 P3 P2 P4

0 7 8 12 16
Average waiting time =
(0+6+3+7)/4 = 4

25
Preemptive SJF
Scheduling(SRTF)

26
Preemptive SJF
Scheduling(SRTF)…

Example 2:
Process Arrival Time Burst Time
P1 0 7
P2 0.2 4
P3 4 1
P4 5 4
Gantt Chart for Schedule

P1 P2 P3 P2 P4 P1

0 2 4 5 7 11 16
Average waiting time =
(9+1+0+2)/4 = 3

27
Determining Length of Next
CPU Burst

One can only estimate the length of burst.


Use the length of previous CPU bursts and
perform exponential averaging.
tn = actual length of nth burst
n+1 =predicted value for the next CPU burst
 = 0, 0    1
Define
• n+1 =  tn + (1- ) n

28
Exponential Averaging(cont.)

 = 0
n+1 = n; Recent history does not count
= 1
n+1 = tn; Only the actual last CPU burst counts.
Similarly, expanding the formula:
j
n+1 = tn + (1-) tn-1 + …+
(1-)^j tn-j + …
(1-)^(n+1) 0
• Each successive term has less weight than its predecessor.

29
4.Priority Scheduling
Priority is assigned for each process.
Process with highest priority is executed first
and so on.
Processes with same priority are executed in
FCFS manner.
Priority can be decided based on memory
requirements, time requirements or any other
resource requirement.

30
Priority Scheduling…

31
Priority Scheduling…

A priority value (integer) is associated with each


process. Can be based on
• Cost to user
• Importance to user
• Aging
• %CPU time used in last X hours.

CPU is allocated to process with the highest


priority.
Preemptive
Nonpreemptive

32
Priority Scheduling (cont.)

SJN is a priority scheme where the priority is the


predicted next CPU burst time.
Problem
Starvation!! - Low priority processes may never execute.
Solution
Aging - as time progresses increase the priority of the
process.

33
4.Round Robin (RR)

A fixed time is allotted to each process, called


quantum, for execution.
Once a process is executed for given time
period that process is preempted and other
process executes for given time period.
Context switching is used to save states of
preempted processes.
Is the preemptive process scheduling algorithm.

34
Round Robin (RR)…
Each process gets a small unit of CPU time
• Time quantum usually 10-100 milliseconds.
• After this time has elapsed, the process is preempted and
added to the end of the ready queue.
n processes, time quantum = q
• Each process gets 1/n CPU time in chunks of at most q time
units at a time.
• No process waits more than (n-1)q time units.
• Performance
– Time slice q too large - FIFO behavior
– Time slice q too small - Overhead of context switch is too
expensive.
– Heuristic - 70-80% of jobs block within timeslice

35
Round Robin Example

Time Quantum = 20
Process Burst Time
P1 53
P2 17
P3 68
P4 24
Gantt Chart for Schedule

P1 P2 P3 P4 P1 P3 P4 P1 P3 P3

0 20 37 57 77 97 117 121 134 154 162

Typically, higher average turnaround time than SRTF, but better response

36
Round Robin Example…

37
5.Multilevel Queue

Ready Queue partitioned into separate queues


• Example: system processes, foreground (interactive),
background (batch), student processes….

Each queue has its own scheduling algorithm


• Example: foreground (RR), background(FCFS)

Processes assigned to one queue permanently.


Scheduling must be done between the queues
• Fixed priority - serve all from foreground, then from
background. Possibility of starvation.
• Time slice - Each queue gets some CPU time that it schedules -
e.g. 80% foreground(RR), 20% background (FCFS)

38
Multilevel Queues

39
Multilevel Feedback Queue

Multilevel Queue with priorities


A process can move between the queues.
• Aging can be implemented this way.

Parameters for a multilevel feedback queue


scheduler:
• number of queues.
• scheduling algorithm for each queue.
• method used to determine when to upgrade a process.
• method used to determine when to demote a process.
• method used to determine which queue a process will enter
when that process needs service.

40
Multilevel Feedback Queues

Example: Three Queues -


• Q0 - time quantum 8 milliseconds (FCFS)
• Q1 - time quantum 16 milliseconds (FCFS)
• Q2 - FCFS

Scheduling
• New job enters Q0 - When it gains CPU, it receives 8
milliseconds. If job does not finish, move it to Q1.
• At Q1, when job gains CPU, it receives 16 more milliseconds.
If job does not complete, it is preempted and moved to queue
Q2.

41
Multilevel Feedback Queues

42
Multiple-Processor
Scheduling

CPU scheduling becomes more complex when


multiple CPUs are available.
Have one ready queue accessed by each CPU.
• Self scheduled - each CPU dispatches a job from ready Q
• Master-Slave - one CPU schedules the other CPUs

Homogeneous processors within multiprocessor.


• Permits Load Sharing

Asymmetric multiprocessing
• only 1 CPU runs kernel, others run user programs
• alleviates need for data sharing

43
Real-Time Scheduling

Hard Real-time Computing -


• required to complete a critical task within a guaranteed
amount of time.

Soft Real-time Computing -


• requires that critical processes receive priority over less
fortunate ones.

Types of real-time Schedulers


• Periodic Schedulers - Fixed Arrival Rate
• Demand-Driven Schedulers - Variable Arrival Rate
• Deadline Schedulers - Priority determined by deadline
• …..

44
Issues in Real-time
Scheduling

Dispatch Latency
• Problem - Need to keep dispatch latency small, OS may
enforce process to wait for system call or I/O to complete.
• Solution - Make system calls preemptible, determine safe
criteria such that kernel can be interrupted.

Priority Inversion and Inheritance


• Problem: Priority Inversion
– Higher Priority Process needs kernel resource currently being
used by another lower priority process..higher priority process
must wait.
• Solution: Priority Inheritance
– Low priority process now inherits high priority until it has
completed use of the resource in question.

45
Real-time Scheduling -
Dispatch Latency

46
Algorithm Evaluation

Deterministic Modeling
• Takes a particular predetermined workload and defines the
performance of each algorithm for that workload. Too specific,
requires exact knowledge to be useful.

Queuing Models and Queuing Theory


• Use distributions of CPU and I/O bursts. Knowing arrival and
service rates - can compute utilization, average queue length,
average wait time etc…
• Little’s formula - n = W where n is the average queue
length,  is the avg. arrival rate and W is the avg. waiting time
in queue.

Other techniques: Simulations, Implementation


47
Principles of
Operating Systems

Chapter Two:
Part 3: The Threads concept
Outline

 The Threads concept


 Types of Threads
 Multi threading models
2.3 The Threads concept
 Processes do not share resources well
 high context switching overhead
 Idea: Separate concurrency from protection
 Multithreading: a single program made up of a number of
different concurrent activities
 A thread (or lightweight process)
 basic unit of CPU utilization; it consists of:
 program counter, register set and stack space
 A thread shares the following with peer threads:
 code section, data section and OS resources (open files, signals)
 No protection between threads
 Collectively called a task.
 Heavyweight process is a task with one thread.
Single and Multithreaded Processes

 Threads encapsulate concurrency: “Active” component


 Address spaces encapsulate protection: “Passive” part
 Keeps buggy program from trashing the system
Benefits
 Responsiveness

 Resource Sharing

 Economy

 Utilization of MP Architectures
Threads(Cont.)

 In a multiple threaded task, while one server


thread is blocked and waiting, a second
thread in the same task can run.
 Cooperation of multiple threads in the same job confers
higher throughput and improved performance.
 Applications that require sharing a common buffer (i.e.
producer-consumer) benefit from thread utilization.
 Threads provide a mechanism that allows
sequential processes to make blocking
system calls while also achieving parallelism.
Thread State
 State shared by all threads in process/addr
space
 Contents of memory (global variables, heap)
 I/O state (file system, network connections, etc)
 State “private” to each thread
 Kept in TCB  Thread Control Block
 CPU registers (including, program counter)
 Execution stack
 Parameters, Temporary variables
 return PCs are kept while called procedures are
executing
Threads (cont.)

 Thread context switch still requires a register


set switch, but no memory management
related work!!
 Thread states -
 ready, blocked, running, terminated
 Threads share CPU and only one thread can
run at a time.
 No protection among threads.
Examples: Multithreaded programs
 Embedded systems
 Elevators, Planes, Medical systems, Wristwatches
 Single Program, concurrent operations
 Most modern OS kernels
 Internally concurrent because have to deal with
concurrent requests by multiple users
 But no protection needed within kernel
 Database Servers
 Access to shared data by many concurrent users
 Also background utility processing must be done
More Examples: Multithreaded programs

 Network Servers
 Concurrent requests from network
 Again, single program, multiple concurrent operations
 File server, Web server, and airline reservation systems

 Parallel Programming (More than one physical CPU)


 Split program into multiple threads for parallelism
 This is called Multiprocessing
# of addr
spaces:
One Many
# threads
Per AS:

MS/DOS, early
One Traditional UNIX
Macintosh
Embedded systems Mach, OS/2, Linux
(Geoworks, VxWorks, Windows 9x???
Many JavaOS,etc)
Win NT to XP, Solaris,
JavaOS, Pilot(PC) HP-UX, OS X

Real operating systems have either


 One or many address spaces
 One or many threads per address space
Types of Threads

 Kernel-supported threads
 User-level threads
 Hybrid approach implements both user-level
and kernel-supported threads (Solaris 2).
Kernel Threads

 Supported by the Kernel


 Native threads supported directly by the kernel
 Every thread can run or block independently
 One process may have several threads waiting on different things

 Downside of kernel threads: a bit expensive


 Need to make a crossing into kernel mode to schedule

 Examples
 Windows XP/2000, Solaris, Linux,Tru64 UNIX,
Mac OS X, Mach, OS/2
User Threads
 Supported above the kernel, via a set of library calls
at the user level.
 Thread management done by user-level threads library
 User program provides scheduler and thread package
 May have several user threads per kernel thread
 User threads may be scheduled non-premptively relative to
each other (only switch on yield())
 Advantages
 Cheap, Fast
 Threads do not need to call OS and cause interrupts to kernel
 Disadv: If kernel is single threaded, system call from any
thread can block the entire task.
 Example thread libraries:
 POSIX Pthreads, Win32 threads, Java threads
Multithreading Models

 Many-to-One

 One-to-One

 Many-to-Many
Many-to-One
 Many user-level threads mapped to single
kernel thread
 Examples:
 Solaris Green Threads
 GNU Portable Threads
One-to-One

 Each user-level thread maps to kernel thread

Examples
 Windows NT/XP/2000; Linux; Solaris 9 and later
Many-to-Many Model
 Allows many user level
threads to be mapped to
many kernel threads
 Allows the operating
system to create a
sufficient number of
kernel threads
 Solaris prior to version 9
 Windows NT/2000 with
the ThreadFiber package
Thread Support in Solaris 2

 Solaris 2 is a version of UNIX with support for


 kernel and user level threads, symmetric multiprocessing
and real-time scheduling.

 Lightweight Processes (LWP)


 intermediate between user and kernel level threads
 each LWP is connected to exactly one kernel thread
Threads in Solaris 2
Threads in Solaris 2

 Resource requirements of thread types


 Kernel Thread: small data structure and stack; thread
switching does not require changing memory access
information - relatively fast.
 Lightweight Process: PCB with register data, accounting
and memory information - switching between LWP is
relatively slow.
 User-level thread: only needs stack and program
counter; no kernel involvement means fast switching.
Kernel only sees the LWPs that support user-level
threads.
Two-level Model
 Similar to M:M, except that it allows a user
thread to be bound to kernel thread
 Examples
 IRIX, HP-UX, Tru64 UNIX, Solaris 8 and earlier
Threading Issues

 Semantics of fork() and exec() system


calls
 Thread cancellation
 Signal handling
 Thread pools
 Thread specific data
Multi( processing, programming, threading)
 Definitions:
 Multiprocessing  Multiple CPUs
 Multiprogramming  Multiple Jobs or Processes
 Multithreading  Multiple threads per Process
 What does it mean to run two threads “concurrently”?
 Scheduler is free to run threads in any order and interleaving: FIFO, Random,

 Dispatcher can choose to run each thread to completion or time-slice in big
chunks or small chunks

Multiprocessing B
C

A B C

Multiprogramming A B C A B C B
Principles of
Operating Systems

Chapter Two:
Part 4: Inter-process Communication (IPC)

Principles of Operating Systems 1


Outline

The Critical Section Problem


Synchronization Hardware
Semaphores
Classical Problems of Synchronization
Critical Regions
Monitors

Principles of Operating Systems 2


Inter-process communication(IPC)

Principles of Operating Systems 3


Inter-process communication(IPC)…

Principles of Operating Systems 4


Other Communication Strategies (Between
Processes) in Client-Server Systems

Principles of Operating Systems 5


Producer-Consumer Problem

Paradigm for cooperating processes;


producer process produces information that is
consumed by a consumer process.
We need buffer of items that can be filled by
producer and emptied by consumer.
• Unbounded-buffer places no practical limit on the size of the
buffer. Consumer may wait, producer never waits.
• Bounded-buffer assumes that there is a fixed buffer size.
Consumer waits for new item, producer waits if buffer is full.
Producer and Consumer must synchronize.

Principles of Operating Systems 6


Producer-Consumer Problem

Principles of Operating Systems 7


Bounded Buffer using IPC
(messaging)

Producer
repeat

produce an item in nextp;

send(consumer, nextp);
until false;
Consumer
repeat
receive(producer, nextc);

consume item from nextc;

until false;

Principles of Operating Systems 8


Bounded-buffer - Shared
Memory Solution

Shared data
var n;
type item = ….;
var buffer: array[0..n-1] of item;
in, out: 0..n-1;
in :=0; out:= 0; /* shared buffer = circular array */
/* Buffer empty if in == out */
/* Buffer full if (in+1) mod n == out */
/* noop means ‘do nothing’ */

Principles of Operating Systems 9


Bounded Buffer - Shared
Memory Solution

Producer process - creates filled buffers


repeat

produce an item in nextp

while in+1 mod n = out do noop;
buffer[in] := nextp;
in := in+1 mod n;
until false;

Principles of Operating Systems 10


Bounded Buffer - Shared
Memory Solution

Consumer process - Empties filled buffers


repeat
while in = out do noop;
nextc := buffer[out] ;
out:= out+1 mod n;

consume the next item in nextc

until false

Principles of Operating Systems 11


Shared data

Concurrent access to shared data may result in


data inconsistency.
Maintaining data consistency requires
mechanisms to ensure the orderly execution of
cooperating processes.
Shared memory solution to the bounded-buffer
problem allows at most (n-1) items in the buffer
at the same time.

Principles of Operating Systems 12


Bounded Buffer

A solution that uses all N buffers is not that


simple.
Modify producer-consumer code by adding a variable
counter, initialized to 0, incremented each time a new item
is added to the buffer
Shared data
type item = ….;
var buffer: array[0..n-1] of item;
in, out: 0..n-1;
counter: 0..n;
in, out, counter := 0;

Principles of Operating Systems 13


Bounded Buffer

Producer process - creates filled buffers


repeat

produce an item in nextp

while counter = n do noop;
buffer[in] := nextp;
in := in+1 mod n;
counter := counter+1;
until false;

Principles of Operating Systems 14


Bounded Buffer

 Consumer process - Empties filled buffers


repeat
while counter = 0 do noop;
nextc := buffer[out] ;
out:= out+1 mod n;
counter := counter - 1;

consume the next item in nextc

until false;
 The statements
counter := counter + 1;
counter := counter - 1;
must be executed atomically.
 Atomic Operations
An operation that runs to completion or not at all.

Principles of Operating Systems 15


Problem is at the lowest level
 If threads are working on separate data, scheduling doesn’t matter:
Thread A Thread B
x = 1; y = 2;
 However, What about (Initially, y = 12):
Thread A Thread B
x = 1; y = 2;
x = y+1; y = y*2;
 What are the possible values of x?
 Or, what are the possible values of x below?
Thread A Thread B
x = 1; x = 2;
 X could be non-deterministic (1, 2??)

Principles of Operating Systems 16


The Critical-Section Problem

N processes all competing to use shared data.


• Structure of process Pi ---- Each process has a code segment,
called the critical section, in which the shared data is accessed.
repeat
entry section /* enter critical section */
critical section /* access shared variables */
exit section /* leave critical section */
remainder section /* do other work */
until false

Problem
• Ensure that when one process is executing in its critical
section, no other process is allowed to execute in its critical
section.

Principles of Operating Systems 17


Solution: Critical Section
Problem - Requirements

Mutual Exclusion
• If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections.
Progress
• If no process is executing in its critical section and there exists
some processes that wish to enter their critical section, then
the selection of the processes that will enter the critical section
next cannot be postponed indefinitely.
Bounded Waiting
• A bound must exist on the number of times that other
processes are allowed to enter their critical sections after a
process has made a request to enter its critical section and
before that request is granted.

Principles of Operating Systems 18


Solution: Critical Section
Problem - Requirements

Assume that each process executes at a


nonzero speed.
No assumption concerning relative speed of the
n processes.

Principles of Operating Systems 19


Solution: Critical Section
Problem -- Initial Attempt

Only 2 processes, P0 and P1


General structure of process Pi (Pj)
repeat
entry section
critical section
exit section
remainder section
until false

Processes may share some common variables to


synchronize their actions.

Principles of Operating Systems 20


Algorithm 1

Shared Variables:
var turn: (0..1);
initially turn = 0;
turn = i  Pi can enter its critical section
Process Pi
repeat
while turn <> i do no-op;
critical section
turn := j;
remainder section
until false
Satisfies mutual exclusion, but not progress.

Principles of Operating Systems 21


Algorithm 2

Shared Variables
var flag: array (0..1) of boolean;
initially flag[0] = flag[1] = false;
flag[i] = true  Pi ready to enter its critical section
Process Pi
repeat
flag[i] := true;
while flag[j] do no-op;
critical section
flag[i]:= false;
remainder section
until false
Can block indefinitely…. Progress requirement not met.

Principles of Operating Systems 22


Algorithm 3

Shared Variables
var flag: array (0..1) of boolean;
initially flag[0] = flag[1] = false;
flag[i] = true  Pi ready to enter its critical section
Process Pi
repeat
while flag[j] do no-op;
flag[i] := true;
critical section
flag[i]:= false;
remainder section
until false
Does not satisfy mutual exclusion requirement ….

Principles of Operating Systems 23


Algorithm 4

Combined Shared Variables of algorithms 1 and 2


Process Pi
repeat
flag[i] := true;
turn := j;
while (flag[j] and turn=j) do no-op;
critical section
flag[i]:= false;
remainder section
until false
YES!!! Meets all three requirements, solves the critical section
problem for 2 processes.

Principles of Operating Systems 24


Bakery Algorithm

Critical section for n processes


Before entering its critical section, process receives a
number. Holder of the smallest number enters critical
section.
If processes Pi and Pj receive the same number,
• if i <= j, then Pi is served first; else Pj is served first.
The numbering scheme always generates numbers in
increasing order of enumeration; i.e. 1,2,3,3,3,3,4,4,5,5

Principles of Operating Systems 25


Bakery Algorithm (cont.)

Notation -
Lexicographic order(ticket#, process id#)
(a,b) < (c,d) if (a<c) or if ((a=c) and (b < d))
max(a0,….an-1) is a number, k, such that k >=ai
for i = 0,…,n-1
Shared Data
var choosing: array[0..n-1] of boolean;(initialized to false)
number: array[0..n-1] of integer; (initialized to 0)

Principles of Operating Systems 26


Bakery Algorithm (cont.)
repeat
choosing[i] := true;
number[i] := max(number[0], number[1],…,number[n-1]) +1;
choosing[i] := false;
for j := 0 to n-1
do begin
while choosing[j] do no-op;
while number[j] <> 0
and (number[j] ,j) < (number[i],i) do no-op;
end;
critical section
number[i]:= 0;
remainder section
until false;

Principles of Operating Systems 27


Supporting Synchronization

Programs Shared Programs

Higher-level
Locks Semaphores Monitors Send/Receive CCregions
API

Hardware Load/Store Disable Ints Test&Set Comp&Swap

 We are going to implement various synchronization primitives using


atomic operations
 Everything is pretty painful if only atomic primitives are load and store
 Need to provide inherent support for synchronization at the hardware level
 Need to provide primitives useful at software/user level

Principles of Operating Systems 28


Hardware Solutions for
Synchronization
 Load/store - Atomic Operations required for synchronization
 Showed how to protect a critical section with only atomic load and
store  pretty complex!
 Mutual exclusion solutions presented depend on memory hardware
having read/write cycle.
• If multiple reads/writes could occur to the same memory location at the same
time, this would not work.
• Processors with caches but no cache coherency cannot use the solutions
 In general, it is impossible to build mutual exclusion without a
primitive that provides some form of mutual exclusion.
How can this be done in the hardware???
How can this be simplified in software???

Principles of Operating Systems 29


Synchronization Hardware

Test and modify the content of a word


atomically - Test-and-set instruction
function Test-and-Set (var target: boolean): boolean;
begin
Test-and-Set := target;
target := true;
end;
Similarly “SWAP” instruction

Principles of Operating Systems 30


Mutual Exclusion with Test-
and-Set

Shared data: var lock: boolean (initially false)


Process Pi
repeat
while Test-and-Set (lock) do no-op;
critical section
lock := false;
remainder section
until false;

Principles of Operating Systems 31


Bounded Waiting Mutual
Exclusion with Test-and-Set
var j : 0..n-1;
key : boolean;
repeat
waiting [i] := true; key := true;
while waiting[i] and key do key := Test-and-Set(lock);
waiting [i ] := false;
critical section
j := i+1 mod n;
while (j <> i ) and (not waiting[j]) do j := j + 1 mod n;
if j = i then lock := false;
else waiting[j] := false;
remainder section

until false;

Principles of Operating Systems 32


Hardware Support: Other
examples

 swap (&address, register) { /* x86 */


temp = M[address];
M[address] = register;
register = temp;
}
 compare&swap (&address, reg1, reg2) { /* 68000 */
if (reg1 == M[address]) {
M[address] = reg2;
return success;
} else {
return failure;
}
}
 load-linked&store conditional(&address) {
/* R4000, alpha */
loop:
ll r1, M[address];
movi r2, 1; /* Can do arbitrary comp */
sc r2, M[address];
beqz r2, loop;
} Principles of Operating Systems 33
Semaphore
 Semaphore S - integer variable (non-negative)
• used to represent number of abstract resources
 Can only be accessed via two indivisible (atomic) operations
wait (S): while S <= 0 do no-op
S := S-1;
signal (S): S := S+1;
• P or wait used to acquire a resource, waits for semaphore to
become positive, then decrements it by 1
• V or signal releases a resource and increments the semaphore
by 1, waking up a waiting P, if any
• If P is performed on a count <= 0, process must wait for V or
the release of a resource.
P():“proberen” (to test) ; V() “verhogen” (to increment) in Dutch

Principles of Operating Systems 34


Example: Critical Section for
n Processes

Shared variables
var mutex: semaphore
initially mutex = 1
Process Pi
repeat
wait(mutex);
critical section
signal (mutex);
remainder section
until false

Principles of Operating Systems 35


Semaphore as a General
Synchronization Tool

Execute B in Pj only after A execute in Pi


Use semaphore flag initialized to 0
Code:
Pi Pj
. .
. .
. .
A wait(flag)
signal(flag) B

Principles of Operating Systems 36


Problem...
 Locks prevent conflicting actions on shared data
 Lock before entering critical section and before accessing shared data
 Unlock when leaving, after accessing shared data
 Wait if locked
 All Synchronization involves waiting
 Busy Waiting, uses CPU that others could use. This type of
semaphore is called a spinlock.
Waiting thread may take cycles away from thread holding lock (no one
wins!)
OK for short times since it prevents a context switch.
Priority Inversion: If busy-waiting thread has higher priority than thread
holding lock  no progress!
Should sleep if waiting for a long time
 For longer runtimes, need to modify P and V so that
processes can block and resume.

Principles of Operating Systems 37


Semaphore Implementation

Define a semaphore as a record


type semaphore = record
value: integer;
L: list of processes;
end;
Assume two simple operations
block suspends the process that invokes it.
wakeup(P) resumes the execution of a blocked process P.

Principles of Operating Systems 38


Semaphore
Implementation(cont.)

Semaphore operations are now defined as


wait (S): S.value := S.value -1;
if S.value < 0
then begin
add this process to S.L;
block;
end;

signal (S): S.value := S.value +1;


if S.value <= 0
then begin
remove a process P from S.L;
wakeup(P);
end;

Principles of Operating Systems 39


Block/Resume Semaphore
Implementation

If process is blocked, enqueue PCB of process


and call scheduler to run a different process.
Semaphores are executed atomically;
no two processes execute wait and signal at the same time.
Mutex can be used to make sure that two processes do not
change count at the same time.
• If an interrupt occurs while mutex is held, it will result in a
long delay.
• Solution: Turn off interrupts during critical section.

Principles of Operating Systems 40


Deadlock and Starvation

Deadlock - two or more processes are waiting


indefinitely for an event that can be caused by only
one of the waiting processes.
Let S and Q be semaphores initialized to 1
P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
.. ..
. .
signal (S) ; signal (Q);
signal (Q); signal (S);
Starvation- indefinite blocking. A process may never
be removed from the semaphore queue in which it is
suspended.

Principles of Operating Systems 41


Two Types of Semaphores

Counting Semaphore - integer value can range


over an unrestricted domain.
Binary Semaphore - integer value can range
only between 0 and 1; simpler to implement.
Can implement a counting semaphore S as a
binary semaphore.

Principles of Operating Systems 42


Classical Problems of
Synchronization

Bounded Buffer Problem


Readers and Writers Problem
Dining-Philosophers Problem

Principles of Operating Systems 43


Bounded Buffer Problem

Shared data
type item = ….;
var buffer: array[0..n-1] of item;
full, empty, mutex : semaphore;
nextp, nextc :item;
full := 0; empty := n; mutex := 1;

Principles of Operating Systems 44


Bounded Buffer Problem

Producer process - creates filled buffers


repeat

produce an item in nextp

wait (empty);
wait (mutex);

add nextp to buffer

signal (mutex);
signal (full);
until false;

Principles of Operating Systems 45


Bounded Buffer Problem

Consumer process - Empties filled buffers


repeat
wait (full );
wait (mutex);

remove an item from buffer to nextc
...
signal (mutex);
signal (empty);

consume the next item in nextc

until false;

Principles of Operating Systems 46


Discussion

 ASymmetry?
 Producer does: P(empty), V(full)
 Consumer does: P(full), V(empty)
 Is order of P’s important?
 Yes! Can cause deadlock
 Is order of V’s important?
 No, except that it might affect scheduling efficiency

Principles of Operating Systems 47


Readers/Writers Problem
W

R
R
R

 Motivation: Consider a shared database


 Two classes of users:
Readers – never modify database
Writers – read and modify database
 Is using a single lock on the whole database sufficient?
Like to have many readers at the same time
Only one writer at a time

Principles of Operating Systems 48


Readers-Writers Problem

Shared Data
var mutex, wrt: semaphore (=1);
readcount: integer (= 0);

Writer Process
wait(wrt);

writing is performed
...
signal(wrt);

Principles of Operating Systems 49


Readers-Writers Problem

Reader process
wait(mutex);
readcount := readcount +1;
if readcount = 1 then wait(wrt);
signal(mutex);
...
reading is performed
...
wait(mutex);
readcount := readcount - 1;
if readcount = 0 then signal(wrt);
signal(mutex);

Principles of Operating Systems 50


Dining-Philosophers Problem

Shared Data
var chopstick: array [0..4] of semaphore (=1 initially);

Principles of Operating Systems 51


Dining Philosophers Problem

Philosopher i :
repeat
wait (chopstick[i]);
wait (chopstick[i+1 mod 5]);

eat
...
signal (chopstick[i]);
signal (chopstick[i+1 mod 5]);

think

until false;

Principles of Operating Systems 52


Higher Level Synchronization

Timing errors are still possible with semaphores


Example 1
signal (mutex);

critical region
...
wait (mutex);
Example 2
wait(mutex);

critical region
...
wait (mutex);
Example 3
wait(mutex);

critical region
...
Forgot to signal

Principles of Operating Systems 53


Motivation for Other Sync. Constructs

 Semaphores are a huge step up from loads and stores


Problem is that semaphores are dual purpose:
They are used for both mutex and scheduling constraints
Example: the fact that flipping of P’s in bounded buffer gives deadlock
is not immediately obvious. How do you prove correctness to
someone?
 Idea: allow manipulation of a shared variable only when condition (if
any) is met – conditional critical region
 Idea : Use locks for mutual exclusion and condition variables for
scheduling constraints
 Monitor: a lock (for mutual exclusion) and zero or more condition
variables (for scheduling constraints ) to manage concurrent access to
shared data
Some languages like Java provide this natively
Principles of Operating Systems 54
Conditional Critical Regions

High-level synchronization construct


A shared variable v of type T is declared as:
var v: shared T
Variable v is accessed only inside statement
region v when B do S
where B is a boolean expression.
While statement S is being executed, no other process
can access variable v.

Principles of Operating Systems 55


Critical Regions (cont.)

Regions referring to the same shared variable


exclude each other in time.
When a process tries to execute the region
statement,
region v when B do S
the Boolean expression B is evaluated.
If B is true, statement S is executed.
If it is false, the process is delayed until B becomes true and
no other process is in the region associated with v.

Principles of Operating Systems 56


Example - Bounded Buffer

Shared variables
var buffer: shared record
pool:array[0..n-1] of item;
count,in,out: integer;
end;
Producer Process inserts nextp into the shared buffer
region buffer when count < n
do begin
pool[in] := nextp;
in := in+1 mod n;
count := count + 1;
end;

Principles of Operating Systems 57


Bounded Buffer Example

Consumer Process removes an item from the shared


buffer and puts it in nextc
region buffer when count > 0
do begin
nextc := pool[out];
out := out+1 mod n;
count := count -1;
end;

Principles of Operating Systems 58


Monitors

High-level synchronization construct that allows the safe sharing of an


abstract data type among concurrent processes.
type monitor-name = monitor
variable declarations
procedure entry P1 (…);
begin … end;
procedure entry P2 (…);
begin … end;
.
.
.
procedure entry Pn(…);
begin … end;
begin
initialization code
end.

Principles of Operating Systems 59


Monitor with Condition
Variables

 Lock: the lock provides mutual exclusion to shared data


 Always acquire before accessing shared data structure
 Always release after finishing with shared data
 Lock initially free
 Condition Variable: a queue of threads waiting for something inside a
critical section
 Key idea: make it possible to go to sleep inside critical section by atomically
releasing lock at time we go to sleep
Principles of Operating Systems 60
Monitors with condition
variables

To allow a process to wait within the monitor, a


condition variable must be declared, as:
var x,y: condition
Condition variable can only be used within the operations
wait and signal. Queue is associated with condition variable.
• The operation
x.wait;
means that the process invoking this operation is suspended until
another process invokes
x.signal;
• The x.signal operation resumes exactly one suspended
process. If no process is suspended, then the signal operation
has no effect.

Principles of Operating Systems 61


Dining Philosophers
type dining-philosophers= monitor
var state: array[0..4] of (thinking, hungry, eating);
var self: array[0..4] of condition;
// condition where philosopher I can delay himself when hungry but
// is unable to obtain chopstick(s)
procedure entry pickup (i :0..4);
begin
state[i] := hungry;
test(i); //test that your left and right neighbors are not eating
if state [i] <> eating then self [i].wait;
end;
procedure entry putdown (i:0..4);
begin
state[i] := thinking;
test (i + 4 mod 5 ); // signal one neighbor
test (i + 1 mod 5 ); // signal other neighbor
end;

Principles of Operating Systems 62


Dining Philosophers (cont.)
procedure test (k :0..4);
begin
if state [k + 4 mod 5] <> eating
and state [k ] = hungry
and state [k + 1 mod 5] <> eating
then
begin
state[k] := eating;
self [k].signal;
end;
end;

begin
for i := 0 to 4
do state[i] := thinking;
end;

Principles of Operating Systems 63


Additional (extra) slides

Principles of Operating Systems 64


Mesa vs. Hoare monitors

 Who proceeds next – signaler or waiter?


 Hoare-style monitors(most textbooks):
Signaler gives lock, CPU to waiter; waiter runs immediately
Waiter gives up lock, processor back to signaler when it exits critical section or if it
waits again
 Mesa-style monitors (most real operating systems):
Signaler keeps lock and processor
Waiter placed on ready queue with no special priority
Practically, need to check condition again after wait (condition may no longer be
true!)
Principles of Operating Systems 65
Implementing S (counting
sem.) as a Binary Semaphore

Data Structures
var S1 : binary-semaphore;
S2 : binary-semaphore;
S3 : binary-semaphore;
C: integer;
Initialization
S1 = S3 =1;
S2 = 0;
C = initial value of semaphore S;

Principles of Operating Systems 66


Implementing S

Wait operation
wait(S3);
wait(S1);
C := C-1;
if C < 0
then begin
signal (S1);
wait(S2);
end
else signal (S1);
signal (S3);
Signal operation
wait(S1);
C := C + 1;
if C <= 0 then signal (S2);
signal (S1);

Principles of Operating Systems 67


Implementing Regions

Region x when B do S
var mutex, first-delay, second-delay: semaphore;
first-count, second-count: integer;
Mutually exclusive access to the critical section
is provided by mutex.
If a process cannot enter the critical section because the
Boolean expression B is false,
it initially waits on the first-delay semaphore;
moved to the second-delay semaphore before it is allowed to
reevaluate B.

Principles of Operating Systems 68


Implementation

Keep track of the number of processes waiting


on first-delay and second-delay, with first-count
and second-count respectively.
The algorithm assumes a FIFO ordering in the
queueing of processes for a semaphore.
For an arbitrary queueing discipline, a more
complicated implementation is required.

Principles of Operating Systems 69


Implementing Regions
wait(mutex);
while not B
do begin first-count := first-count +1;
if second-count > 0
then signal (second-delay);
else signal (mutex);
wait(first-delay);
first-count := first-count -1;
second-count := second-count + 1;
if first-count > 0 then signal (first-delay)
else signal (second-delay);
wait(second-delay);
second-count := second-count -1;
end;
S;
if first-count > 0 then signal (first-delay);
else if second-count > 0
then signal (second-delay);
else signal (mutex);

Principles of Operating Systems 70


Principles of
Operating Systems

Chapter Two:
Part 5: Deadlocks
Outline

 System Model
 Deadlock Characterization
 Methods for handling deadlocks
 Deadlock Prevention
 Deadlock Avoidance
 Deadlock Detection
 Recovery from Deadlock
 Combined Approach to Deadlock Handling
The Deadlock Problem

 A set of blocked processes each holding a


resource and waiting to acquire a resource
held by another process in the set.
 Example 1
 System has 2 tape drives. P1 and P2 each hold one tape
drive and each needs the other one.
 Example 2
 Semaphores A and B each initialized to 1
P0 P1
wait(A) wait(B)
wait(B) wait(A)
Definitions

 A process is deadlocked if it is waiting for an


event that will never occur.
Typically, more than one process will be involved in a
deadlock (the deadly embrace).
 A process is indefinitely postponed if it is
delayed repeatedly over a long period of time
while the attention of the system is given to
other processes,
 i.e. the process is ready to proceed but never gets the
CPU.
Example - Bridge Crossing

 Assume traffic in one direction.


 Each section of the bridge is viewed as a resource.
 If a deadlock occurs, it can be resolved only if one
car backs up (preempt resources and rollback).
 Several cars may have to be backed up if a deadlock
occurs.
 Starvation is possible
Resources

 Resource
 commodity required by a process to execute
 Resources can be of several types
 Serially Reusable Resources
 CPU cycles, memory space, I/O devices, files
 acquire -> use -> release
 Consumable Resources
 Produced by a process, needed by a process - e.g.
Messages, buffers of information, interrupts
 create ->acquire ->use
 Resource ceases to exist after it has been used
System Model

 Resource types
 R1, R2,….Rm
 Each resource type Ri has Wi instances
 Assume serially reusable resources
 request -> use -> release
Conditions for Deadlock
 The following 4 conditions are necessary and sufficient for
deadlock (must hold simultaneously)
 Mutual Exclusion:
 Only one process at a time can use the resource.
 Hold and Wait:
 Processes hold resources already allocated to them while
waiting for other resources.
 No preemption:
 Resources are released by processes holding them only after
that process has completed its task.
 Circular wait:
 A circular chain of processes exists in which each process
waits for one or more resources held by the next process in the
chain.
Resource Allocation Graph

 A set of vertices V and a set of edges E


 V is partitioned into 2 types
 P = {P1, P2,…,Pn} - the set of processes in the system
 R = {R1, R2,…,Rn} - the set of resource types in the
system
 Two kinds of edges
 Request edge - Directed edge Pi ---> Rj
 Assignment edge - Directed edge Rj ----> Pi
Resource Allocation Graph

 Process

 Resource type with 4 instances

 Pi requests instance of Rj

 Pi is holding an instance of Rj
Graph with no cycles

R1 R2

P1 P2 P3

R3 R4
Graph with cycles

R1 P2

P1 P3

R2 P4
Graph with cycles and deadlock
R1 R2

P1 P2 P3

R3 R4
Basic facts

 If graph contains no cycles


 NO DEADLOCK
 If graph contains a cycle
 if only one instance per resource type, then
deadlock
 if several instances per resource type, possibility
of deadlock.
Methods for handling deadlocks

 Ensure that the system will never enter a


deadlock state.
 Allow the system to potentially enter a
deadlock state, detect it and then recover
 Ignore the problem and pretend that
deadlocks never occur in the system;
 Used by many operating systems, e.g. UNIX
Deadlock Management

 Prevention
 Design the system in such a way that deadlocks can never
occur
 Avoidance
 Impose less stringent conditions than for prevention, allowing
the possibility of deadlock but sidestepping it as it occurs.
 Detection
 Allow possibility of deadlock, determine if deadlock has
occurred and which processes and resources are involved.
 Recovery
 After detection, clear the problem, allow processes to complete
and resources to be reused. May involve destroying and
restarting processes.
Deadlock Prevention

 If any one of the conditions for deadlock (with


reusable resources) is denied, deadlock is
impossible.
 Restrain ways in which requests can be made
 Mutual Exclusion
 non-issue for sharable resources
 cannot deny this for non-sharable resources (important)
 Hold and Wait - guarantee that when a process requests
a resource, it does not hold other resources.
 Force each process to acquire all the required resources at
once. Process cannot proceed until all resources have
been acquired.
 Low resource utilization, starvation possible
Deadlock Prevention (cont.)

 No Preemption
 If a process that is holding some resources requests
another resource that cannot be immediately allocated to it,
the process releases the resources currently being held.
 Preempted resources are added to the list of resources for
which the process is waiting.
 Process will be restarted only when it can regain its old
resources as well as the new ones that it is requesting.
 Circular Wait
 Impose a total ordering of all resource types.
 Require that processes request resources in increasing
order of enumeration; if a resource of type N is held,
process can only request resources of types > N.
Deadlock Avoidance

 Set of resources, set of customers, banker


 Rules
 Each customer tells banker maximum number of resources
it needs.
 Customer borrows resources from banker.
 Customer returns resources to banker.
 Customer eventually pays back loan.

 Banker only lends resources if the system


will be in a safe state after the loan.
Deadlock Avoidance

 Requires that the system has some additional


apriori information available.
 Simplest and most useful model requires that each process
declare the maximum number of resources of each type
that it may need.
 The deadlock-avoidance algorithm dynamically examines
the resource-allocation state to ensure that there can never
be a circular-wait condition.
 Resource allocation state is defined by the number of
available and allocated resources, and the maximum
demands of the processes.
Safe state

 When a process requests an available resource, system must


decide if immediate allocation leaves the system in a safe
state.
 System is in safe state if there exists a safe sequence of all
processes.
 Sequence <P1, P2, …Pn> is safe, if for each Pi, the resources
that Pi can still request can be satisfied by currently available
resources + resources held by Pj with j<i.
 If Pi resource needs are not available, Pi can wait until all Pj have
finished.
 When Pj is finished, Pi can obtain needed resources, execute,
return allocated resources, and terminate.
 When Pi terminates, Pi+1 can obtain its needed resources...
Basic Facts

 If a system is in a safe state  no


deadlocks.
 If a system is in unsafe state  possibility of
deadlock.
 Avoidance  ensure that a system will never
reach an unsafe state.
Resource Allocation Graph Algorithm

 Used for deadlock avoidance when there is


only one instance of each resource type.
 Claim edge: Pi  Rj indicates that process Pi may request
resource Rj; represented by a dashed line.
 Claim edge converts to request edge when a process
requests a resource.
 When a resource is released by a process, assignment
edge reconverts to claim edge.
 Resources must be claimed a priori in the system.
 If request assignment does not result in the formation of
a cycle in the resource allocation graph - safe state, else
unsafe state.
Claim Graph

Process claims resource

Process requests resource

Process is assigned resource

Process releases resource


Claim Graph
1 2

Possible Deadlock!! 3
6

5 4
Banker’s Algorithm

 Used for multiple instances of each resource


type.
 Each process must a priori claim maximum
use of each resource type.
 When a process requests a resource it may
have to wait.
 When a process gets all its resources it must
return them in a finite amount of time.
Data Structures for the Banker’s
Algorithm
 Let n = number of processes and m =
number of resource types.
 Available: Vector of length m. If Available[j] = k, there are k
instances of resource type Rj available.
 Max: n  m matrix. If Max[i,j] = k, then process Pi may
request at most k instances of resource type Rj.
 Allocation: n  m matrix. If Allocation[i,j] = k, then process
Pi is currently allocated k instances of resource type Rj.
 Need: n  m matrix. If Need[i,j] = k, then process Pi may
need k more instances of resource type Rj to complete its
task.

Need[i,j] = Max[i,j] - Allocation[i,j]


Safety Algorithm

 Let Work and Finish be vectors of length m and n,


respectively. Initialize
 Work := Available
 Finish[i] := false for i = 1,2,…,n.
 Find an i (i.e. process Pi) such that both:
 Finish[i] = false
 Need_i <= Work
 If no such i exists, go to step 4.
 Work := Work + Allocation_i
 Finish[i] := true
 go to step 2
 If Finish[i] = true for all i, then the system is in a safe
state.
Resource-Request Algorithm for
Process Pi
 Request_i = request vector for process Pi. If
Request_i[j] = k, then process Pi wants k instances of
resource type Rj.
 STEP 1: If Request(i)  Need(i), go to step 2. Otherwise, raise
error condition, since process has exceeded its maximum
claim.
 STEP 2: If Request(i)  Available, go to step 3. Otherwise, Pi
must wait since resources are not available.
 STEP 3: Pretend to allocate requested resources to Pi by
modifying the state as follows:
Available := Available - Request (i);
Allocation (i) := Allocation (i) + Request (i);
Need (i) := Need (i) - Request (i);
 If safe  resources are allocated to Pi.
 If unsafe  Pi must wait and the old resource-allocation state
is restored.
Example of Banker’s Algorithm

 5 processes
 P0 - P4;
 3 resource types
 A(10 instances), B (5 instances), C (7 instances)
 Snapshot at time T0

Allocation Max Available


A B C A B C A B C
P0 0 1 0 7 5 3 3 3 2
P1 2 0 0 3 2 2
P2 3 0 2 9 0 2
P3 2 1 1 2 2 2
P4 0 0 2 4 3 3
Example (cont.)

 The content of the matrix Need is defined to


be Max - Allocation.
 The system is in a safe state since the
sequence <P1,P3,P4,P2,P0> satisfies safety
criteria.
Need
A B C
P0 7 4 3
P1 1 2 2
P2 6 0 0
P3 0 1 1
P4 4 3 1
Example: P1 requests (1,0,2)

 Check to see that Request  Available


 ((1,0,2)  (3,3,2))  true.

Allocation Need Available


A B C A B C A B C
P0 0 1 0 7 4 3 2 3 0
P1 3 0 2 0 2 0
P2 3 0 2 6 0 0
P3 2 1 1 0 1 1
P4 0 0 2 4 3 1
Example (cont.)

 Executing the safety algorithm shows that


sequence <P1, P3, P4, P0, P2> satisfies
safety requirement.
 Can request for (3,3,0) by P4 be granted?
 Can request for (0,2,0) by P0 be granted?
Deadlock Detection

 Allow system to enter deadlock state


 Detection Algorithm
 Recovery Scheme
Single Instance of each resource type

 Maintain wait-for graph


 Nodes are processes
 Pi  Pj if Pi is waiting for Pj.
 Periodically invoke an algorithm that
searches for a cycle in the graph.
 An algorithm to detect a cycle in a graph
requires an order of n^2 operations, where n
is the number of vertices in the graph.
Several instances of a resource type

 Data Structures
 Available: Vector of length m. If Available[j] = k, there are k
instances of resource type Rj available.
 Allocation: n  m matrix. If Allocation[i,j] = k, then process
Pi is currently allocated k instances of resource type Rj.
 Request : An n  m matrix indicates the current request of
each process. If Request [i,j] = k, then process Pi is
requesting k more instances of resource type Rj .
Deadlock Detection Algorithm

 Step 1: Let Work and Finish be vectors of length m and


n, respectively. Initialize
 Work := Available
 For i = 1,2,…,n, if Allocation(i)  0, then Finish[i] := false,
otherwise Finish[i] := true.
 Step 2: Find an index i such that both:
 Finish[i] = false
 Request (i)  Work
 If no such i exists, go to step 4.
Deadlock Detection Algorithm

 Step 3: Work := Work + Allocation(i)


 Finish[i] := true
 go to step 2
 Step 4: If Finish[i] = false for some i, 1  i  n, then the
system is in a deadlock state. Moreover, if Finish[i] =
false, then Pi is deadlocked.

Algorithm requires an order of m  (n^2) operations


to detect whether the system is in a deadlocked
state.
Example of Detection Algorithm

 5 processes - P0 - P4; 3 resource types - A(7


instances), B(2 instances), C(6 instances)
 Snapshot at time T 0: <P0,P2,P3,P1,P4> will result in
Finish[i] = true for all i.

Allocation Request Available


A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0
P1 2 0 0 2 0 2
P2 3 0 3 0 0 0
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2
Example (cont.)
 P2 requests an additional instance of type C.
 State of system
 Can reclaim resources held by process P0, but insufficient
resources to fulfill other processes’ requests.
 Deadlock exists, consisting of P 1,P 2,P 3 and P 4.
Request
A B C
P0 0 0 0
P1 2 0 2
P2 0 0 1
P3 1 0 0
P4 0 0 2
Detection-Algorithm Use

 When, and how often to invoke depends on:


 How often a deadlock is likely to occur?
 How many processes will need to be rolled back?
 One for each disjoint cycle
 How often --
 Every time a request for allocation cannot be granted
immediately
 Allows us to detect set of deadlocked processes and process
that “caused” deadlock. Extra overhead.
 Every hour or whenever CPU utilization drops.
 With arbitrary invocation there may be many cycles in the
resource graph and we would not be able to tell which of the
many deadlocked processes “caused” the deadlock.
Recovery from Deadlock: Process
Termination
 Abort all deadlocked processes.
 Abort one process at a time until the deadlock
cycle is eliminated.
 In which order should we choose to abort?
 Priority of the process
 How long the process has computed, and how much longer
to completion.
 Resources the process has used.
 Resources process needs to complete.
 How many processes will need to be terminated.
 Is process interactive or batch?
Recovery from Deadlock: Resource
Preemption
 Selecting a victim - minimize cost.
 Rollback
 return to some safe state, restart process from that
state.
 Starvation
 same process may always be picked as victim; include
number of rollback in cost factor.
Combined approach to deadlock
handling
 Combine the three basic approaches
 Prevention
 Avoidance

 Detection

allowing the use of the optimal approach for each class of


resources in the system.
 Partition resources into hierarchically ordered
classes.
 Use most appropriate technique for handling
deadlocks within each class.
Principles of Operating Systems

Chapter Three: Memory Management:

Part I:Main Memory


Outline

■ Background
■ Logical versus Physical Address Space
■ Swapping
■ Contiguous Allocation
■ Paging
■ Segmentation
■ Segmentation with Paging
Background

■ Program must be brought into memory and


placed within a process for it to be executed.
■ Input Queue - collection of processes on the
disk that are waiting to be brought into
memory for execution.
■ User programs go through several steps
before being executed.
Virtualizing Resources
■ Physical Reality: Processes/Threads share the same
hardware
❑ Need to multiplex CPU (CPU Scheduling)
❑ Need to multiplex use of Memory (Today)

■ Why worry about memory multiplexing?


❑ The complete working state of a process and/or kernel is defined
by its data in memory (and registers)
❑ Consequently, cannot just let different processes use the same
memory
❑ Probably don’t want different processes to even have access to
each other’s memory (protection)
Important Aspects of Memory Multiplexing

■ Controlled overlap:
❑ Processes should not collide in physical memory
❑ Conversely, would like the ability to share memory when desired (for
communication)

■ Protection:
❑ Prevent access to private memory of other processes
■ Different pages of memory can be given special behavior (Read Only,
Invisible to user programs, etc)
■ Kernel data protected from user programs

■ Translation:
❑ Ability to translate accesses from one address space (virtual) to a
different one (physical)
❑ When translation exists, process uses virtual addresses, physical
memory uses physical addresses
Names and Binding

❑ Symbolic names → Logical names → Physical


names
■ Symbolic Names: known in a context or path
❑ file names, program names, printer/device names, user
names
■ Logical Names: used to label a specific entity
❑ inodes, job number, major/minor device numbers, process
id (pid), uid, gid..
■ Physical Names: address of entity
❑ inode address on disk or memory
❑ entry point or variable address
❑ PCB address
Binding of instructions and data to
memory
❑ Address binding of instructions and data to memory
addresses can happen at three different stages.
■ Compile time:
❑ If memory location is known a priori, absolute code can be
generated; must recompile code if starting location changes.
■ Load time:
❑ Must generate relocatable code if memory location is not
known at compile time.
■ Execution time:
❑ Binding delayed until runtime if the process can be moved
during its execution from one memory segment to another.
Need hardware support for address maps (e.g. base and limit
registers).
Binding time tradeoffs

❑ Early binding
❑ compiler - produces efficient code
❑ allows checking to be done early
❑ allows estimates of running time and space

❑ Delayed binding
❑ Linker, loader
❑ produces efficient code, allows separate compilation
❑ portability and sharing of object code
❑ Late binding
❑ VM, dynamic linking/loading, overlaying, interpreting
❑ code less efficient, checks done at runtime
❑ flexible, allows dynamic reconfiguration
Multi-step Processing of a Program for Execution

■ Preparation of a program for execution


involves components at:
❑ Compile time (i.e., “gcc”)
❑ Link/Load time (unix “ld” does link)
❑ Execution time (e.g. dynamic libs)

■ Addresses can be bound to final values


anywhere in this path
❑ Depends on hardware support
❑ Also depends on operating system

■ Dynamic Libraries
❑ Linking postponed until execution
❑ Small piece of code, stub, used to locate
appropriate memory-resident library routine
❑ Stub replaces itself with the address of the
routine, and executes routine
Dynamic Loading

■ Routine is not loaded until it is called.


■ Better memory-space utilization; unused
routine is never loaded.
■ Useful when large amounts of code are
needed to handle infrequently occurring
cases.
■ No special support from the operating system
is required; implemented through program
design.
Dynamic Linking

■ Linking postponed until execution time.


■ Small piece of code, stub, used to locate the
appropriate memory-resident library routine.
■ Stub replaces itself with the address of the
routine, and executes the routine.
■ Operating system needed to check if routine
is in processes’ memory address.
Overlays

■ Keep in memory only those instructions and


data that are needed at any given time.
■ Needed when process is larger than amount
of memory allocated to it.
■ Implemented by user, no special support
from operating system; programming design
of overlay structure is complex.
Overlaying
Logical vs. Physical Address Space

❑ The concept of a logical address space that is


bound to a separate physical address space is
central to proper memory management.
■ Logical Address: or virtual address - generated by CPU
■ Physical Address: address seen by memory unit.
❑ Logical and physical addresses are the same in
compile time and load-time binding schemes
❑ Logical and physical addresses differ in
execution-time address-binding scheme.
Memory Management Unit (MMU)

■ Hardware device that maps virtual to physical


address.
■ In MMU scheme, the value in the relocation
register is added to every address generated
by a user process at the time it is sent to
memory.
■ The user program deals with logical
addresses; it never sees the real physical
address.
Swapping

❑ A process can be swapped temporarily out of


memory to a backing store and then brought back
into memory for continued execution.
❑ Backing Store - fast disk large enough to accommodate
copies of all memory images for all users; must provide
direct access to these memory images.
❑ Roll out, roll in - swapping variant used for priority based
scheduling algorithms; lower priority process is swapped
out, so higher priority process can be loaded and executed.
❑ Major part of swap time is transfer time; total transfer time
is directly proportional to the amount of memory swapped.
❑ Modified versions of swapping are found on many systems,
i.e. UNIX and Microsoft Windows.
Schematic view of swapping
Contiguous Allocation

■ Main memory usually into two partitions


■ Resident Operating System, usually held in low memory
with interrupt vector.
■ User processes then held in high memory.
■ Single partition allocation
■ Relocation register scheme used to protect user
processes from each other, and from changing OS code
and data.
■ Relocation register contains value of smallest physical
address; limit register contains range of logical
addresses - each logical address must be less than the
limit register.
Relocation Register
Relocation and Limit Registers
Fixed partitions
Contiguous Allocation (cont.)

■ Multiple partition Allocation


■ Hole - block of available memory; holes of various sizes
are scattered throughout memory.
■ When a process arrives, it is allocated memory from a
hole large enough to accommodate it.
■ Operating system maintains information about
❑ allocated partitions
❑ free partitions (hole)
Contiguous Allocation example

OS OS OS OS
Process 5 Process 5 Process 5 Process 5
Process 9 Process 9

Process 8 Process 10

Process 2 Process 2 Process 2 Process 2


Dynamic Storage Allocation
Problem
❑ How to satisfy a request of size n from a list of free holes.
■ First-fit
❑ allocate the first hole that is big enough
■ Best-fit
❑ Allocate the smallest hole that is big enough; must search
entire list, unless ordered by size. Produces the smallest
leftover hole.
■ Worst-fit
❑ Allocate the largest hole; must also search entire list. Produces
the largest leftover hole.
❑ First-fit and best-fit are better than worst-fit in terms of
speed and storage utilization.
Fragmentation
■ External fragmentation
❑ total memory space exists to satisfy a request, but it is
not contiguous.
■ Internal fragmentation
❑ allocated memory may be slightly larger than requested
memory; this size difference is memory internal to a
partition, but not being used.
■ Reduce external fragmentation by compaction
❑ Shuffle memory contents to place all free memory
together in one large block
❑ Compaction is possible only if relocation is dynamic, and
is done at execution time.
❑ I/O problem - (1) latch job in memory while it is in I/O (2)
Do I/O only into OS buffers.
Fragmentation example
Compaction
Paging

■ Logical address space of a process can be non-


contiguous;
■ process is allocated physical memory wherever the latter is
available.
■ Divide physical memory into fixed size blocks called frames
❑ size is power of 2, 512 bytes - 8K
■ Divide logical memory into same size blocks called pages.
❑ Keep track of all free frames.
❑ To run a program of size n pages, find n free frames and load
program.
■ Set up a page table to translate logical to physical addresses.
■ Note:: Internal Fragmentation possible!!
Address Translation Scheme

■ Address generated by CPU is divided into:


■ Page number(p)
❑ used as an index into page table which contains base
address of each page in physical memory.
■ Page offset(d)
❑ combined with base address to define the physical memory
address that is sent to the memory unit.
Address Translation Architecture
Example of Paging
Page Table Implementation

■ Page table is kept in main memory


■ Page-table base register (PTBR) points to the page table.
■ Page-table length register (PTLR) indicates the size of page
table.
❑ Every data/instruction access requires 2 memory accesses.
■ One for page table, one for data/instruction
■ Two-memory access problem solved by use of special fast-
lookup hardware cache (i.e. cache page table in registers)
❑ associative registers or translation look-aside buffers (TLBs)
Translation Lookaside Buffer (TLB)
(aka Associative Registers)
Page # Frame #
Address Translation
(A, A’)

■ If A is in TLB, get frame #


■ Otherwise, need to go to page table for
frame#
■ requires additional memory reference
❑ Page Hit ratio - percentage of time page is found
in TLB.
Paging hardware with TLB
Effective Access time

■ TLB lookup time = ε time unit


■ Assume Memory cycle time = 1 microsecond
■ Hit ratio = α
■ Effective access time (EAT)
❑ EAT = (1+ ε) α + (2+ ε) (1-α)

❑ EAT = 2+ ε - α
Memory Protection

■ Implemented by associating protection bits


with each frame.
■ Valid/invalid bit attached to each entry in
page table.
❑ Valid: indicates that the associated page is in the
process’ logical address space.
❑ Invalid: indicates that the page is not in the
process’ logical address space.
Two Level Page Table Scheme
Page of Physical memory
page-tables
Outer-page table 1
: :
500

100
: :
708
:
:
929
: :
900
Two Level Paging Example

■ A logical address (32bit machine, 4K page size) is


divided into
❑ a page number consisting of 20 bits, a page offset
consisting of 12 bits
■ Since the page table is paged, the page number
consists of
❑ a 10-bit page number, a 10-bit page offset
■ Thus, a logical address is organized as (p1,p2,d) where
❑ p1 is an index into the outer page table
❑ p2 is the displacement within the page of the outer page
table
Page number Page offset
p1 p2 d
Two Level Paging Example
Multilevel paging

■ Each level is a separate table in memory


❑ converting a logical address to a physical one may take 4
or more memory accesses.
❑ Caching can help performance remain
reasonable.
■ Assume cache hit rate is 98%, memory access time is
quintupled (100 vs. 500 nanoseconds), cache lookup
time is 20 nanoseconds
■ Effective Access time = 0.98 * 120 + .02 * 520 = 128 ns
■ This is only a 28% slowdown in memory access time...
Inverted Page Table

■ One entry for each real page of memory


■ Entry consists of virtual address of page in real memory
with information about process that owns page.
❑ Decreases memory needed to store page table
❑ Increases time to search table when a page
reference occurs
■ table sorted by physical address, lookup by virtual
address
❑ Use hash table to limit search to one (maybe few)
page-table entries.
Inverted Page Table
Shared pages

■ Code and data can be shared among processes


■ Reentrant (non self-modifying) code can be shared.
■ Map them into pages with common page frame mappings
■ Single copy of read-only code - compilers, editors etc..
■ Shared code must appear in the same location in
the logical address space of all processes
■ Private code and data
■ Each process keeps a separate copy of code and data
■ Pages for private code and data can appear anywhere in
logical address space.
Shared Pages
Segmentation

■ Memory Management Scheme that supports


user view of memory.
■ A program is a collection of segments.
■ A segment is a logical unit such as
❑ main program, procedure, function
❑ local variables, global variables,common block
❑ stack, symbol table, arrays
■ Protect each entity independently
■ Allow each segment to grow independently
■ Share each segment independently
Logical view of segmentation

1
2

1
4

2 4
3

User Space Physical Memory


Segmentation Architecture

❑ Logical address consists of a two tuple


<segment-number, offset>
❑ Segment Table
■ Maps two-dimensional user-defined addresses into one-
dimensional physical addresses. Each table entry has
❑ Base - contains the starting physical address where the
segments reside in memory.
❑ Limit - specifies the length of the segment.

■ Segment-table base register (STBR) points to the segment


table’s location in memory.
■ Segment-table length register (STLR) indicates the number
of segments used by a program; segment number is legal if s
< STLR.
Segmentation Architecture (cont.)

❑ Relocation is dynamic - by segment table


❑ Sharing
■ Code sharing occurs at the segment level.
■ Shared segments must have same segment number.
❑ Allocation - dynamic storage allocation problem
■ use best fit/first fit, may cause external fragmentation.
❑ Protection
■ protection bits associated with segments
❑ read/write/execute privileges
❑ array in a separate segment - hardware can check for
illegal array indexes.
Shared segments

editor 0
1 43062
segment 0
data 1 Segment Table editor
68348
process P1
data 1
segment 1 72773
Logical Memory
process P1

editor 90003
0
segment 0 data 2 data 2
1
98553
Segment Table
Logical Memory process P2
process P2 segment 1
Segmentation hardware
Segmented Paged Memory

❑ Segment-table entry contains not the base


address of the segment, but the base address of
a page table for this segment.
■ Overcomes external fragmentation problem of
segmented memory.
■ Paging also makes allocation simpler; time to search
for a suitable segment (using best-fit etc.) reduced.
■ Introduces some internal fragmentation and table
space overhead.
❑ Multics - single level page table
❑ IBM OS/2 - OS on top of Intel 386
■ uses a two level paging scheme
MULTICS address translation scheme

52
Principles of Operating Systems

Chapter Three: Memory Management:

Part II: Virtual Memory


Virtual Memory

■ Background
■ Demand paging
❑ Performance of demand paging
■ Page Replacement
❑ Page Replacement Algorithms
■ Allocation of Frames
■ Thrashing
■ Demand Segmentation
Need for Virtual Memory

■ Virtual Memory
■ Separation of user logical memory from physical
memory.
■ Only PART of the program needs to be in memory for
execution.
■ Logical address space can therefore be much larger
than physical address space.
■ Need to allow pages to be swapped in and out.
■ Virtual Memory can be implemented via
❑ Paging
❑ Segmentation
Paging/Segmentation Policies

■ Fetch Strategies
■ When should a page or segment be brought into primary
memory from secondary (disk) storage?
❑ Demand Fetch
❑ Anticipatory Fetch
■ Placement Strategies
■ When a page or segment is brought into memory, where
is it to be put?
❑ Paging - trivial
❑ Segmentation - significant problem
■ Replacement Strategies
■ Which page/segment should be replaced if there is not
enough room for a required page/segment?
Demand Paging

■ Bring a page into memory only when it is


needed.
❑ Less I/O needed
❑ Less Memory needed
❑ Faster response
❑ More users
■ The first reference to a page will trap to OS
with a page fault.
■ OS looks at another table to decide
❑ Invalid reference - abort
❑ Just not in memory.
Valid-Invalid Bit

❑ With each page table entry a valid-invalid bit is


associated (1 ⇒ in-memory, 0 ⇒ not in memory).
❑ Initially, valid-invalid bit is set to 0 on all entries.
■ During address translation, if valid-invalid bit in page
table entry is 0 --- page fault occurs.
■ Example of a page-table snapshot
Frame # Valid-invalid bit

Page Table
Handling a Page Fault
❑ Page is needed - reference to page
❑ Step 1: Page fault occurs - trap to OS (process suspends).
❑ Step 2: Check if the virtual memory address is valid. Kill
job if invalid reference. If valid reference, and page not in
memory, continue.
❑ Step 3: Bring into memory - Find a free page frame, map
address to disk block and fetch disk block into page frame.
When disk read has completed, add virtual memory
mapping to indicate that page is in memory.
❑ Step 4: Restart instruction interrupted by illegal address
trap. The process will continue as if page had always been
in memory.
What happens if there is no free
frame?
■ Page replacement - find some page in
memory that is not really in use and swap it.
■ Need page replacement algorithm
■ Performance Issue - need an algorithm which will result
in minimum number of page faults.
❑ Same page may be brought into memory many
times.
Performance of Demand Paging

■ Page Fault Ratio - 0 ≤ p ≤ 1.0


❑ If p = 0, no page faults
❑ If p = 1, every reference is a page fault
■ Effective Access Time
EAT = (1-p) * memory-access +
p * (page fault overhead +
swap page out +
swap page in +
restart overhead)
Demand Paging Example

■ Memory Access time = 1 microsecond


■ 50% of the time the page that is being
replaced has been modified and therefore
needs to be swapped out.
■ Swap Page Time = 10 msec = 10,000
microsec
EAT = (1-p) *1 + p (15000) ≈1 + 15000p microsec
■ EAT is directly proportional to the page fault
rate.
Page Replacement

■ Prevent over-allocation of memory by


modifying page fault service routine to
include page replacement.
■ Use modify(dirty) bit to reduce overhead of
page transfers - only modified pages are
written to disk.
■ Page replacement
■ large virtual memory can be provided on a smaller
physical memory.
Page Replacement Algorithms

■ Want lowest page-fault rate.


■ Evaluate algorithm by running it on a
particular string of memory references
(reference string) and computing the number
of page faults on that string.
■ Assume reference string in examples to
follow is
1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5.
Page Replacement Strategies
■ The Principle of Optimality
❑ Replace the page that will not be used again the farthest time
into the future.
■ Random Page Replacement
❑ Choose a page randomly
■ FIFO - First in First Out
❑ Replace the page that has been in memory the longest.
■ LRU - Least Recently Used
❑ Replace the page that has not been used for the longest time.
■ LFU - Least Frequently Used
❑ Replace the page that is used least often.
■ NUR - Not Used Recently
❑ An approximation to LRU
■ Working Set
❑ Keep in memory those pages that the process is actively using
First-In-First-Out (FIFO) Algorithm

Reference String: 1,2,3,4,1,2,5,1,2,3,4,5


■ Assume x frames ( x pages can be in
memory at a time per process)

3 frames 9 Page faults

10 Page faults
4 frames

FIFO Replacement - Belady’s Anomaly -- more frames does not mean less page faults
Optimal Algorithm

■ Replace page that will not be used for longest


period of time.
❑ How do you know this???
❑ Generally used to measure how well an algorithm
performs.

6 Page faults
4 frames
Least Recently Used (LRU)
Algorithm
❑ Use recent past as an approximation of near
future.
❑ Choose the page that has not been used for the
longest period of time.
❑ May require hardware assistance to implement.
❑ Reference String: 1,2,3,4,1,2,5,1,2,3,4,5

4 frames

8 Page faults
Implementation of LRU algorithm

■ Counter Implementation
❑ Every page entry has a counter; every time page is referenced
through this entry, copy the clock into the counter.
❑ When a page needs to be changes, look at the counters to
determine which page to change (page with smallest time value).
■ Stack Implementation
■ Keeps a stack of page numbers in a doubly linked form
■ Page referenced
❑ move it to the top
❑ requires 6 pointers to be changed
■ No search required for replacement
LRU Approximation Algorithms

❑ Reference Bit
❑ With each page, associate a bit, initially = 0.
❑ When page is referenced, bit is set to 1.
❑ Replace the one which is 0 (if one exists). Do not know
order however.
❑ Additional Reference Bits Algorithm
❑ Record reference bits at regular intervals.
❑ Keep 8 bits (say) for each page in a table in memory.
❑ Periodically, shift reference bit into high-order bit, I.e. shift
other bits to the right, dropping the lowest bit.
❑ During page replacement, interpret 8bits as unsigned
integer.
❑ The page with the lowest number is the LRU page.
LRU Approximation Algorithms

❑ Second Chance
■ FIFO (clock) replacement algorithm
■ Need a reference bit.
■ When a page is selected, inspect the reference bit.
■ If the reference bit = 0, replace the page.
■ If page to be replaced (in clock order) has reference bit
= 1, then
❑ set reference bit to 0
❑ leave page in memory
❑ replace next page (in clock order) subject to same rules.
LRU Approximation Algorithms

❑ Enhanced Second Chance


■ Need a reference bit and a modify bit as an ordered pair.
■ 4 situations are possible:
❑ (0,0) - neither recently used nor modified - best page to
replace.
❑ (0,1) - not recently used, but modified - not quite as good,
because the page will need to be written out before
replacement.
❑ (1,0) - recently used but clean - probably will be used again
soon.
❑ (1,1) - probably will be used again, will need to write out before
replacement.
❑ Used in the Macintosh virtual memory management scheme
Counting Algorithms

■ Keep a counter of the number of references


that have been made to each page.
❑ LFU (least frequently used) algorithm
■ replaces page with smallest count.
■ Rationale : frequently used page should have a large
reference count.
❑ Variation - shift bits right, exponentially decaying count.
❑ MFU (most frequently used) algorithm
■ replaces page with highest count.
■ Based on the argument that the page with the smallest
count was probably just brought in and has yet to be
used.
Page Buffering Algorithm

■ Keep pool of free frames


■ Solution 1
❑ When a page fault occurs, choose victim frame.
❑ Desired page is read into free frame from pool before victim is
written out.
❑ Allows process to restart soon, victim is later written out and
added to free frame pool.
■ Solution 2
❑ Maintain a list of modified pages. When paging device is idle,
write modified pages to disk and clear modify bit.
■ Solution 3
❑ Keep frame contents in pool of free frames and remember
which page was in frame.. If desired page is in free frame pool,
no need to page in.
Protection Bits
Page Protection

Segmentation Protection

Reference - Page has been accessed


Valid - Page exists
Resident - Page is cached in primary memory
Dirty - Page has been changed since page in
Allocation of Frames

❑ Single user case is simple


❑ User is allocated any free frame
❑ Problem: Demand paging + multiprogramming
■ Each process needs minimum number of pages based on
instruction set architecture.
■ Example IBM 370: 6 pages to handle MVC (storage to
storage move) instruction
❑ Instruction is 6 bytes, might span 2 pages.
❑ 2 pages to handle from.
❑ 2 pages to handle to.

■ Two major allocation schemes:


❑ Fixed allocation
❑ Priority allocation
Fixed Allocation

■ Equal Allocation
❑ E.g. If 100 frames and 5 processes, give each 20 pages.
■ Proportional Allocation
■ Allocate according to the size of process
❑ Sj = size of process Pj
❑ S = ∑Sj
❑ m = total number of frames
❑ aj = allocation for Pj = Sj/S * m
❑ If m = 64, S1 = 10, S2 = 127 then
a1 = 10/137 * 64 ≈ 5
a2 = 127/137 * 64 ≈ 59
Priority Allocation

■ May want to give high priority process more


memory than low priority process.
■ Use a proportional allocation scheme using
priorities instead of size
■ If process Pi generates a page fault
■ select for replacement one of its frames
■ select for replacement a frame form a process with
lower priority number.
Global vs. Local Allocation

■ Global Replacement
■ Process selects a replacement frame from the set of all
frames.
■ One process can take a frame from another.
■ Process may not be able to control its page fault rate.
■ Local Replacement
■ Each process selects from only its own set of allocated
frames.
■ Process slowed down even if other less used pages of
memory are available.
■ Global replacement has better throughput
■ Hence more commonly used.
Thrashing

■ If a process does not have enough pages,


the page-fault rate is very high. This leads to:
■ low CPU utilization.
■ OS thinks that it needs to increase the degree of
multiprogramming
■ Another process is added to the system.
■ System throughput plunges...
❑ Thrashing
■ A process is busy swapping pages in and out.
■ In other words, a process is spending more time paging
than executing.
Thrashing (cont.)

❑ Why does paging work?


❑ Locality Model - computations have locality!
❑ Locality - set of pages that are actively used together.
❑ Process migrates from one locality to another.
❑ Localities may overlap.

29
Thrashing

❑ Why does thrashing occur?


■ ∑ (size of locality) > total memory size
Working Set Model

■ Δ ≡ working-set window
■ a fixed number of page references, e.g. 10,000 instructions
❑ WSSj (working set size of process Pj) - total number of
pages referenced in the most recent Δ (varies in time)
■ If Δ too small, will not encompass entire locality.
■ If Δ too large, will encompass several localities.
■ If Δ = ∞, will encompass entire program.
❑ D = ∑ WSSj ≡ total demand frames
■ If D > m (number of available frames) ⇒thrashing
❑ Policy: If D > m, then suspend one of the processes.
Keeping Track of the Working Set

■ Approximate with
■ interval timer + a reference bit
❑ Example: Δ = 10,000
❑ Timer interrupts after every 5000 time units.
❑ Whenever a timer interrupts, copy and set the values of all
reference bits to 0.
❑ Keep in memory 2 bits for each page (indicated if page was used
within last 10,000 to 15,000 references).
❑ If one of the bits in memory = 1 ⇒ page in working set.
■ Not completely accurate - cannot tell where reference
occurred.
■ Improvement - 10 bits and interrupt every 1000 time units.
Page fault Frequency Scheme

■ Control thrashing by establishing acceptable page-fault


rate.
❑ If page fault rate too low, process loses frame.
❑ If page fault rate too high, process needs and gains a
frame.

33
Demand Paging Issues

❑ Prepaging
■ Tries to prevent high level of initial paging.
❑ E.g. If a process is suspended, keep list of pages in
working set and bring entire working set back before
restarting process.
❑ Tradeoff - page fault vs. prepaging - depends on how many
pages brought back are reused.
❑ Page Size Selection
■ fragmentation
■ table size
■ I/O overhead
■ locality
Demand Paging Issues

❑ Program Structure
■ Array A[1024,1024] of integer
■ Assume each row is stored on one page
■ Assume only one frame in memory
■ Program 1
for j := 1 to 1024 do
for i := 1 to 1024 do
A[i,j] := 0;
1024 * 1024 page faults
■ Program 2
for i := 1 to 1024 do
for j:= 1 to 1024 do
A[i,j] := 0;
1024 page faults
Demand Paging Issues

■ I/O Interlock and addressing


■ Say I/O is done to/from virtual memory. I/O is
implemented by I/O controller.
❑ Process A issues I/O request
❑ CPU is given to other processes
❑ Page faults occur - process A’s pages are paged out.
❑ I/O now tries to occur - but frame is being used for another
process.
■ Solution 1: never execute I/O to memory - I/O takes
place into system memory. Copying Overhead!!
■ Solution 2: Lock pages in memory - cannot be selected
for replacement.
Demand Segmentation

■ Used when there is insufficient hardware to


implement demand paging.
■ OS/2 allocates memory in segments, which it
keeps track of through segment descriptors.
■ Segment descriptor contains valid bit to indicate whether
the segment is currently in memory.
❑ If segment is in main memory, access continues.
❑ If not in memory, segment fault.
Principles of Operating Systems

Chapter Four: File System Interface


and Implementation
Outline

■ File Concept and Structure


■ Directory Structures
■ File Organizations
■ Access Methods
■ Protection
File Concept

❑ Contiguous logical address space


■ OS abstracts from the physical properties of its storage
device to define a logical storage unit called file.
■ Persistent
■ OS maps files to physical devices.
❑ Types
■ Data
❑ numeric, character, binary
■ Program
❑ source, object (load image)
■ Documents
File Structure
❑ None - sequence of words/bytes
❑ Simple record structure
❑ Lines
❑ Fixed Length
❑ Variable Length
❑ Complex Structures
❑ Formatted document
❑ Relocatable Load File
❑ Can simulate last two with first method by
inserting appropriate control characters
❑ Who decides
❑ Operating System
❑ Program
File Attributes
❑ Name
❑ symbolic file-name, only information in human-readable form
❑ Identifier
❑ Unique tag that identifies file within filesystem; non-human readable name
❑ Type -
❑ for systems that support multiple types
❑ Location -
❑ pointer to a device and to file location on device
❑ Size -
❑ current file size, maximal possible size
❑ Protection -
❑ controls who can read, write, execute
❑ Time, Date and user identification
❑ data for protection, security and usage monitoring
❑ Information about files are kept in the directory structure,
maintained on disk
File types - name.extension
File Operations
❑ A file is an abstract data type. It can be defined by
operations:
■ Create a file
■ Write a file
■ Read a file
■ Reposition within file - file seek
■ Delete a file
■ Truncate a file
■ Open(Fi)
❑ search the directory structure on disk for entry Fi, and move the
content of entry to memory.
■ Close(Fi)
❑ move the content of entry Fi in memory to directory structure on
disk.
Directory Structure

❑ Number of files on a system can be extensive


❑ Break file systems into partitions ( treated as a separate
storage device)
❑ Hold information about files within partitions.
❑ Device Directory: A collection of nodes containing
information about all files on a partition.
❑ Both the directory structure and files reside on
disk.
❑ Backups of these two structures are kept on
tapes.
Information in a Device Directory

❑ File Name
❑ File Type

❑ Address or Location

❑ Current Length

❑ Maximum Length

❑ Date created, Date last accessed (for archival),


Date last updated (for dump)
❑ Owner ID (who pays), Protection information
■ Also on a per file, per process basis
❑ Current position - read/write position
❑ usage count
Operations Performed on Directory

❑ Search for a file


❑ Create a file
❑ Delete a file
❑ List a directory
❑ Rename a file
❑ Traverse the filesystem
Logical Directory Organization --
Goals
■ Efficiency - locating a file quickly
■ Naming - convenient to users
■ Two users can have the same name for different files.
■ The same file can have several different names.
■ Grouping
■ Logical grouping of files by properties (e.g. all Python
programs, all games, all pictures…)
Single Level Directory

■ A single directory for all users


■ Naming Problem and Grouping Problem
❑ As the number of files increases, difficult to remember
unique names
❑ As the number of users increase, users must have unique
names.
Two Level Directory

■ Introduced to remove naming problem


between users
❑ First Level contains list of user directories
❑ Second Level contains user files
❑ Need to specify Path name
❑ Can have same file names for different users.
❑ System files kept in separate directory or Level 1.
❑ Efficient searching
Two Level Directory
Tree structured Directories
Tree Structured Directories

■ Arbitrary depth of directories


■ Leaf nodes are files, interior nodes are directories.
■ Efficient Searching
■ Grouping Capability
■ Current Directory (working directory)
■ cd /spell/mail/prog, cd ..
■ dir, ls
■ MS-DOS uses a tree structured directory
Tree Structured Directories

❑ Absolute or relative path name


❑ Absolute from root
❑ Relative paths from current working directory pointer.
❑ Creating a new file is done in current directory
❑ Creating a new subdirectory is done in current
directory, e.g. mkdir <dir-name>
❑ Delete a file , e.g. rm file-name
❑ Deletion of directory
■ Option 1 : Only delete if directory is empty
■ Option 2: delete all files and subdirectories under
directory
Acyclic Graph Directories
Acyclic Graph Directories

■ Acyclic graphs allow sharing


■ Implementation by links
■ Links are pointers to other files or subdirectories
■ Symbolic links or relative path name
❑ Directory entry is marked as a link and name of real
file/directory is given. Need to resolve link to locate file.
■ Implementation by shared files
■ Duplicate information in sharing directories
■ Original and copy indistinguishable.
■ Need to maintain consistency if one of them is modified.
Acyclic Graph Directories

❑ Naming : File may have multiple absolute path names


■ Two different names for the same file
❑ Traversal
❑ ensure that shared data structures are traversed only once.
❑ Deletion
■ Removing file when someone deletes it may leave dangling
pointers.
■ Preserve file until all references to it are deleted
❑ Keep a list of all references to a file or
❑ Keep a count of the number of references - reference count.
❑ When count = 0, file can be deleted.
General Graph Directories
General Graph Directories (cont.)

❑ How do we guarantee no cycles in a tree


structured directory?
❑ Allow only links to file not subdirectories.
❑ Every time a new link is added use a cycle detection
algorithm to determine whether it is ok.
❑ If links to directories are allowed, we have a
simple graph structure
❑ Need to ensure that components are not traversed twice
both for correctness and for performance, e.g. search
can be non-terminating.
❑ File Deletion - reference count can be non-zero
❑ Need garbage collection mechanism to determine if file
can be deleted.
Access Methods

■ Sequential Access
read next
write next
reset
no read after last write (rewrite)
■ Direct Access ( n = relative block number)
read n
write n
position to n
read next
write next
rewrite n
Sequential File Organization
Indexed Sequential or Indexed
File Organization
Direct Access File Organization
Protection

■ File owner/creator should be able to control


■ what can be done
■ by whom
■ Types of access
❑ read
❑ write
❑ execute
❑ append
❑ delete
❑ list
Access lists and groups
❑ Associate each file/directory with access list
■ Problem - length of access list..
❑ Solution - condensed version of list
■ Mode of access: read, write, execute
■ Three classes of users
❑ owner access - user who created the file
❑ groups access - set of users who are sharing the file and need
similar access
❑ public access - all other users
■ In UNIX, 3 fields of length 3 bits are used.
❑ Fields are user, group, others(u,g,o),
❑ Bits are read, write, execute (r,w,x).
❑ E.g. chmod go+rw file , chmod 761 game
File-System Implementation

■ File System Structure


■ Allocation Methods
■ Free-Space Management
■ Directory Implementation
■ Efficiency and Performance
■ Recovery
File-System Structure

■ File Structure
■ Logical Storage Unit with collection of related
information
❑ File System resides on secondary storage (disks).
■ To improve I/O efficiency, I/O transfers between memory
and disk are performed in blocks.
❑ Read/Write/Modify/Access each block on disk.
■ File system organized into layers.
■ File control block - storage structure
consisting of information about a file.
File System Mounting

■ File System must be mounted before it can


be available to process on the system
■ The OS is given the name of the device and the mount
point (location within file structure at which files attach).
■ OS verifies that the device contains a valid file system.
■ OS notes in its directory structure that a file system is
mounted at the specified mount point.
Allocation of Disk Space

■ Low level access methods depend upon the


disk allocation scheme used to store file data
❑ Contiguous Allocation
❑ Linked List Allocation
❑ Indexed Allocation
Contiguous Allocation
❑ Each file occupies a set of contiguous blocks on the disk.
❑ Simple - only starting location (block #) and length (number of
blocks) are required.
❑ Suits sequential or direct access.
❑ Fast (very little head movement) and easy to recover in the
event of system crash.
■ Problems
❑ Wasteful of space (dynamic storage-allocation problem). Use
first fit or best fit. Leads to external fragmentation on disk.
❑ Files cannot grow - expanding file requires copying
❑ Users tend to overestimate space - internal fragmentation.
❑ Mapping from logical to physical - <Q,R>
❑ Block to be accessed = Q + starting address
❑ Displacement into block = R
Contiguous Allocation
Linked Allocation

■ Each file is a linked list of disk blocks


■ Blocks may be scattered anywhere on the disk.
■ Each node in list can be a fixed size physical block or a
contiguous collection of blocks.
■ Allocate as needed and then link together via pointers.
❑ Disk space used to store pointers, if disk block is 512 bytes,
and pointer (disk address) requires 4 bytes, user sees 508
bytes of data.
■ Pointers in list not accessible to user.
pointer
Block =
Data
Linked Allocation
Linked Allocation

❑ Simple - need only starting address.


❑ Free-space management system - space efficient.
■ Can grow in middle and at ends. No estimation of size
necessary.
❑ Suited for sequential access but not random
access.
❑ Directory Table maps files into head of list for a
file.
❑ Mapping - <Q, R>
❑ Block to be accessed is the Qth block in the linked chain of
blocks representing the file.
❑ Displacement into block = R + 1
Linked Allocation (cont.)

❑ Slow - defies principle of locality.


❑ Need to read through linked list nodes sequentially to find
the record of interest.
❑ Not very reliable
❑ System crashes can scramble files being updated.
❑ Important variation on linked allocation method
■ File-allocation table (FAT) - disk-space allocation used
by MS-DOS and OS/2.
File Allocation Table (FAT)

■ Instead of link on each


block, put all links in
one table
❑ the File Allocation Table
— i.e., FAT
■ One entry per physical
block in disk
❑ Directory points to first
& last blocks of file
❑ Each block points to
next block (or EOF)

File Implementations 39
CS-4513, D-Term 2007
FAT File Systems

■ Advantages
❑ Advantages of Linked File System
❑ FAT can be cached in memory
❑ Searchable at CPU speeds, pseudo-random access
■ Disadvantages
❑ Limited size, not suitable for very large disks
❑ FAT cache describes entire disk, not just open files!
❑ Not fast enough for large databases

■ Used in MS-DOS, early Windows systems

File Implementations CS-4513, D-Term 2007 40


Disk Defragmentation

■ Re-organize blocks in disk so that file is


(mostly) contiguous
■ Link or FAT organization preserved
■ Purpose:
❑ To reduce disk arm movement during sequential
accesses

File Implementations CS-4513, D-Term 2007 41


Indexed Allocation

■ Brings all pointers together into the index


block.
■ Logical view

Index table
Indexed Allocation

43
Indexed Allocation (cont.)

■ Need index table.


■ Supports sequential, direct and indexed access.
■ Dynamic access without external fragmentation, but
have overhead of index block.
❑ Mapping from logical to physical in a file of maximum size
of 256K words and block size of 512 words. We need only
1 block for index table.
■ Mapping - <Q,R>
❑ Q - displacement into index table
❑ R - displacement into block
Indexed Allocation - Mapping

❑ Mapping from logical to physical in a file of


unbounded length.
❑ Linked scheme -
■ Link blocks of index tables (no limit on size)
❑ Multilevel Index
■ E.g. Two Level Index - first level index block points to a
set of second level index blocks, which in turn point to
file blocks.
■ Increase number of levels based on maximum file size
desired.
■ Maximum size of file is bounded.
Indexed File - Linked Scheme
Index block file block

link

link
Indexed Allocation - Multilevel
index 2nd level Index

Index block

link

link
Combined Scheme: UNIX Inode
mode data
owners
timestamps data
Size block
count data

Direct blocks

data
data
data
data
Single indirect data
double indirect data

Triple indirect data

48
What is an inode?

■ An inode (index node) is a control structure that contains


key information needed by the OS to access a particular
file. Several file names may be associated with a single
inode, but each file is controlled by exactly ONE inode.

■ On the disk, there is an inode table that contains the


inodes of all the files in the filesystem. When a file is
opened, its inode is brought into main memory and stored
in a memory-resident inode table.

Copyright ©: Nahrstedt, Angrave,


Abdelzaher 49
Information in the inode

Copyright ©: Nahrstedt, Angrave,


Abdelzaher 50
Directories
■ In Unix a directory is simply a file that contains a list of file
names plus pointers to associated inodes

Inode table
Directory

i1 Name1

i2 Name2

i3 Name3

i4 Name4


Copyright ©: Nahrstedt, Angrave,

Abdelzaher

51
Free Space Management

■ Bit Vector (n blocks) - bit map of free blocks


0 1 2 n-1 1 implies block[i] free
bit[i] = { 0 implies block[i] occupied

■ Block number calculation


(number of bits per word) *
(number of 0-value words) +
offset of 1st bit
■ Bit map requires extra space.
❑ Eg. Block size = 2^12 bytes, Disk size = 2^30 bytes
n = 2^30/2^12 = 2^18 bits ( or 32K bytes)
■ Easy to get contiguous files
■ Example: BSD File system
Free Space Management

❑ Linked list (free list)


❑ Keep a linked list of free blocks
❑ Cannot get contiguous space easily, not very efficient because
linked list needs traversal.
❑ No waste of space

❑ Linked list of indices - Grouping


❑ Keep a linked list of index blocks. Each index block contains
addresses of free blocks and a pointer to the next index block.
❑ Can find a large number of free blocks contiguously.

❑ Counting
❑ Linked list of contiguous blocks that are free
❑ Free list node contains pointer and number of free blocks
starting from that address.
Free Space Management

■ Need to protect
■ pointer to free list
■ Bit map
❑ Must be kept on disk
❑ Copy in memory and disk may differ.
❑ Cannot allow for block[i] to have a situation where bit[i] = 1
in memory and bit[i] = 0 on disk
■ Solution
❑ Set bit[i] = 1 in disk
❑ Allocate block[i]
❑ Set bit[i] = 1 in memory.
Directory Implementation

■ Linear list of file names with pointers to the data


blocks
■ simple to program
■ time-consuming to execute - linear search to find entry.
■ Sorted list helps - allows binary search and decreases search
time.
■ Hash Table - linear list with hash data structure
■ decreases directory search time
■ collisions - situations where two file names hash to the same
location.
■ Each hash entry can be a linked list - resolve collisions by
adding new entry to linked list.
Efficiency and Performance
❑ Efficiency dependent on:
❑ disk allocation and directory algorithms
❑ types of data kept in the files directory entry
❑ Dynamic allocation of kernel structures
❑ Performance improved by:
■ On-board cache - for disk controllers
■ Disk Cache - separate section of main memory for frequently
used blocks. Block replacement mechanisms
❑ LRU
❑ Free-behind - removes block from buffer as soon as next block
is requested.
❑ Read-ahead - request block and several subsequent blocks are
read and cached.
■ Improve PC performance by dedicating section of memory as
virtual disk or RAM disk.
Recovery

■ Ensure that system failure does not result in


loss of data or data inconsistency.
■ Consistency checker
■ compares data in directory structure with data blocks on
disk and tries to fix inconsistencies.
■ Backup
■ Use system programs to back up data from disk to
another storage device (floppy disk, magnetic tape).
■ Restore
■ Recover lost file or disk by restoring data from backup.
Principles of Operating Systems

Chapter Five: Input Output Management:

5.1: I/O Hardware


One of the important jobs of an Operating System is to manage various I/O devices including
mouse, keyboards, touch pad, disk drives, display adapters, USB devices, Bit- mapped screen,
LED, Analog-to-digital converter, On/off switch, network connections, audio I/O, printers etc.

An I/O system is required to take an application I/O request and send it to the physical device,
then take whatever response comes back from the device and send it to the application. I/O
devices can be divided into two categories −

 Block devices − A block device is one with which the driver communicates by sending entire
blocks of data. For example, Hard disks, USB cameras, Disk-On-Key etc.

 Character devices − A character device is one with which the driver communicates by sending
and receiving single characters (bytes, octets). For example, serial ports, parallel ports, sounds
cards etc

Device Controllers
Device drivers are software modules that can be plugged into an OS to handle a particular
device. Operating System takes help from device drivers to handle all I/O devices.

The Device Controller works like an interface between a device and a device driver. I/O units
(Keyboard, mouse, printer, etc.) typically consist of a mechanical component and an electronic
component where electronic component is called the device controller.

There is always a device controller and a device driver for each device to communicate with the
Operating Systems. A device controller may be able to handle multiple device s. As an interface
its main task is to convert serial bit stream to block of bytes, perform error correction as
necessary.

Any device connected to the computer is connected by a plug and socket, and the socket is
connected to a device controller. Following is a model for connecting the CPU, memory,
controllers, and I/O devices where CPU and device controllers all use a common bus for
communication.

Synchronous vs asynchronous I/O


 Synchronous I/O − In this scheme CPU execution waits while I/O proceeds

 Asynchronous I/O − I/O proceeds concurrently with CPU execution

Communication to I/O Devices


The CPU must have a way to pass information to and from an I/O device. There are three
approaches available to communicate with the CPU and Device.

 Special Instruction I/O

 Memory-mapped I/O

 Direct memory access (DMA)


Special Instruction I/O
This uses CPU instructions that are specifically made for controlling I/O devices. These
instructions typically allow data to be sent to an I/O device or read from an I/O device.

Memory-mapped I/O
When using memory- mapped I/O, the same address space is shared by memory and I/O devices.
The device is connected directly to certain main memory locations so that I/O device can
transfer block of data to/from memory without going through CPU.
While using memory mapped IO, OS allocates buffer in memory and informs I/O device to use
that buffer to send data to the CPU. I/O device operates asynchronously with CPU, interrupts
CPU when finished.

The advantage to this method is that every instruction which can access memory can be used to
manipulate an I/O device. Memory mapped IO is used for most high-speed I/O devices like
disks, communication interfaces.

Direct Memory Access (DMA)


Slow devices like keyboards will generate an interrupt to the main CPU after each byte is
transferred. If a fast device such as a disk generated an interrupt for each byte, the operating
system would spend most of its time handling these interrupts. So a typical computer uses direct
memory access (DMA) hardware to reduce this overhead.

Direct Memory Access (DMA) means CPU grants I/O module authority to read from or write to
memory without involvement. DMA module itself controls exchange of data between main
memory and the I/O device. CPU is only involved at the beginning and end of the transfer and
interrupted only after entire block has been transferred.

Direct Memory Access needs a special hardware called DMA controller (DMAC) that manages
the data transfers and arbitrates access to the system bus. The controllers are programmed with
source and destination pointers (where to read/write the data), counters to track the number of
transferred bytes, and settings, which includes I/O and memory types, interrupts and states for
the CPU cycles.
The operating system uses the DMA hardware as follows −

Step Description

1 Device driver is instructed to transfer disk data to a buffer address X.

2 Device driver then instruct disk controller to transfer data to buffer.

3 Disk controller starts DMA transfer.

4 Disk controller sends each byte to DMA controller.

5 DMA controller transfers bytes to buffer, increases the memory address, decreases the counter
C until C becomes zero.

6 When C becomes zero, DMA interrupts CPU to signal transfer completion.

Polling vs Interrupts I/O


A computer must have a way of detecting the arrival of any type of input. There are two ways
that this can happen, known as polling and interrupts. Both of these techniques allow the
processor to deal with events that can happen at any time and that are not related to the process
it is currently running.

Polling I/O
Polling is the simplest way for an I/O device to communicate with the processor. The process of
periodically checking status of the device to see if it is time for the next I/O operation, is called
polling. The I/O device simply puts the information in a Status register, and the processor must
come and get the information.

Most of the time, devices will not require attention and when one does it will have to wait until
it is next interrogated by the polling program. This is an inefficient method and much of the
processors time is wasted on unnecessary polls.

Compare this method to a teacher continually asking every student in a class, one after another,
if they need help. Obviously the more efficient method would be for a student to inform the
teacher whenever they require assistance.

Interrupts I/O
An alternative scheme for dealing with I/O is the interrupt-driven method. An interrupt is a
signal to the microprocessor from a device that requires attention.

A device controller puts an interrupt signal on the bus when it needs CPU’s attention when CPU
receives an interrupt, It saves its current state and invokes the appropriate interrupt handler
using the interrupt vector (addresses of OS routines to handle various events). When the
interrupting device has been dealt with, the CPU continues with its original task as if it had
never been interrupted.
5.2: I/O Softwares
I/O software is often organized in the following layers −

 User Level Libraries − This provides simple interface to the user program to perform input and
output. For example, stdio is a library provided by C and C++ programming languages.

 Kernel Level Modules − This provides device driver to interact with the device controller and
device independent I/O modules used by the device drivers.

 Hardware − This layer includes actual hardware and hardware controller which interact with the
device drivers and makes hardware alive.

A key concept in the design of I/O software is that it should be device independent where it
should be possible to write programs that can access any I/O device without having to specify
the device in advance. For example, a program that reads a file as input should be able to read a
file on a floppy disk, on a hard disk, or on a CD-ROM, without having to modify the program
for each different device.
Device Drivers
Device drivers are software modules that can be plugged into an OS to handle a particular
device. Operating System takes help from device drivers to handle all I/O devices. Device
drivers encapsulate device-dependent code and implement a standard interface in such a way
that code contains device-specific register reads/writes. Device driver, is generally written by
the device's manufacturer and delivered along with the device on a CD-ROM.

A device driver performs the following jobs −

 To accept request from the device independent software above to it.

 Interact with the device controller to take and give I/O and perform required error handling

 Making sure that the request is executed successfully

How a device driver handles a request is as follows: Suppose a request comes to read a block N.
If the driver is idle at the time a request arrives, it starts carrying out the request immediately.
Otherwise, if the driver is already busy with some other request, it places the new request in the
queue of pending requests.

Interrupt handlers
An interrupt handler, also known as an interrupt service routine or ISR, is a piece of software or
more specifically a callback function in an operating system or more specifically in a device
driver, whose execution is triggered by the reception of an interrupt.

When the interrupt happens, the interrupt procedure does whatever it has to in order to handle
the interrupt, updates data structures and wakes up process that was waiting for an interrupt to
happen.

The interrupt mechanism accepts an address ─ a number that selects a specific interrupt
handling routine/function from a small set. In most architectures, this address is an offset stored
in a table called the interrupt vector table. This vector contains the memory addresses of
specialized interrupt handlers.

Device-Independent I/O Software


The basic function of the device- independent software is to perform the I/O functions that are
common to all devices and to provide a uniform interface to the user- level software. Though it
is difficult to write completely device independent software but we can write some modules
which are common among all the devices. Following is a list of functions of device- independent
I/O Software −

 Uniform interfacing for device drivers

 Device naming - Mnemonic names mapped to Major and Minor device numbers

 Device protection

 Providing a device-independent block size

 Buffering because data coming off a device cannot be stored in final destination.

 Storage allocation on block devices

 Allocation and releasing dedicated devices

 Error Reporting
User-Space I/O Software
These are the libraries which provide richer and simplified interface to access the functionality
of the kernel or ultimately interactive with the device drivers. Most of the user- level I/O
software consists of library procedures with some exception like spooling system which is a
way of dealing with dedicated I/O devices in a multiprogramming system.

I/O Libraries (e.g., stdio) are in user-space to provide an interface to the OS resident device-
independent I/O SW. For example putchar(), getchar(), printf() and scanf() are example of user
level I/O library stdio available in C programming.

Kernel I/O Subsystem


Kernel I/O Subsystem is responsible to provide many services related to I/O. Following are
some of the services provided.

 Scheduling − Kernel schedules a set of I/O requests to determine a good order in which to
execute them. When an application issues a blocking I/O system call, the request is placed on the
queue for that device. The Kernel I/O scheduler rearranges the order of the queue to improve the
overall system efficiency and the average response time experienced by the applications.

 Buffering − Kernel I/O Subsystem maintains a memory area known as buffer that stores data
while they are transferred between two devices or between a device with an application
operation. Buffering is done to cope with a speed mismatch between the producer and consumer
of a data stream or to adapt between devices that have different data transfer sizes.

 Caching − Kernel maintains cache memory which is region of fast memory that holds copies of
data. Access to the cached copy is more efficient than access to the original.

 Spooling and Device Reservation − A spool is a buffer that holds output for a device, such as a
printer, that cannot accept interleaved data streams. The spooling system copies the queued
spool files to the printer one at a time. In some operating systems, spooling is managed by a
system daemon process. In other operating systems, it is handled by an in kernel thread.

 Error Handling − An operating system that uses protected memory can guard against many
kinds of hardware and application errors.
Principles of Operating Systems

Chapter Six: Security

6.1 Security
Security refers to providing a protection system to computer system resources such as CPU,
memory, disk, software programs and most importantly data/information stored in the computer
system. If a computer program is run by an unauthorized user, then he/she may cause severe
damage to computer or data stored in it. So a computer system must be protected against
unauthorized access, malicious access to system memory, viruses, worms etc. We're going to
discuss following topics in this chapter.

 Authentication

 One Time passwords

 Program Threats

 System Threats

 Computer Security Classifications

Authentication
Authentication refers to identifying each user of the system and associating the executing
programs with those users. It is the responsibility of the Operating System to create a protection
system which ensures that a user who is running a particular program is authentic. Operating
Systems generally identifies/authenticates users using following three ways −

 Username / Password − User need to enter a registered username and password with Operating
system to login into the system.

 User card/key − User need to punch card in card slot, or enter key generated by key generator in
option provided by operating system to login into the system.

 User attribute - fingerprint/ eye retina pattern/ signature − User need to pass his/her attribute
via designated input device used by operating system to login into the system.
One Time passwords
One-time passwords provide additional security along with normal authentication. In One-Time
Password system, a unique password is required every time user tries to login into the system.
Once a one-time password is used, then it cannot be used again. One-time password are
implemented in various ways.

 Random numbers − Users are provided cards having numbers printed along with corresponding
alphabets. System asks for numbers corresponding to few alphabets randomly chosen.

 Secret key − User are provided a hardware device which can create a secret id mapped with user
id. System asks for such secret id which is to be generated every time prior to login.

 Network password − Some commercial applications send one-time passwords to user on


registered mobile/ email which is required to be entered prior to login.

Program Threats
Operating system's processes and kernel do the designated task as instructed. If a user program
made these process do malicious tasks, then it is known as Program Threats. One of the
common example of program threat is a program installed in a comp uter which can store and
send user credentials via network to some hacker. Following is the list of some well-known
program threats.

 Trojan Horse − Such program traps user login credentials and stores them to send to malicious
user who can later on login to computer and can access system resources.

 Trap Door − If a program which is designed to work as required, have a security hole in its code
and perform illegal action without knowledge of user then it is called to have a trap door.

 Logic Bomb − Logic bomb is a situation when a program misbehaves only when certain
conditions met otherwise it works as a genuine program. It is harder to detect.

 Virus − Virus as name suggest can replicate themselves on computer system. They are highly
dangerous and can modify/delete user files, crash systems. A virus is generatlly a small code
embedded in a program. As user accesses the program, the virus starts getting embedded in other
files/ programs and can make system unusable for user
System Threats
System threats refers to misuse of system services and network connections to put user in
trouble. System threats can be used to launch program threats on a complete network called as
program attack. System threats creates such an environment that operating system resources/
user files are misused. Following is the list of some well-known system threats.

 Worm − Worm is a process which can choked down a system performance by using system
resources to extreme levels. A Worm process generates its multiple copies where each copy use s
system resources, prevents all other processes to get required resources. Worms processes can
even shut down an entire network.

 Port Scanning − Port scanning is a mechanism or means by which a hacker can detects system
vulnerabilities to make an attack on the system.

 Denial of Service − Denial of service attacks normally prevents user to make legitimate use of
the system. For example, a user may not be able to use internet if denial of service attacks
browser's content settings.

Computer Security Classifications


As per the U.S. Department of Defense Trusted Computer System's Evaluation Criteria there
are four security classifications in computer systems: A, B, C, and D. This is widely used
specifications to determine and model the security of syste ms and of security solutions.
Following is the brief description of each classification.

S.N. Classification Type & Description

1
Type A

Highest Level. Uses formal design specifications and verification techniques. Grants a high
degree of assurance of process security.

2
Type B

Provides mandatory protection system. Have all the properties of a class C2 system. Attaches
a sensitivity label to each object. It is of three types.

 B1 − Maintains the security label of each object in the system. Label is used for
making decisions to access control.

 B2 − Extends the sensitivity labels to each system resource, such as storage objects,
supports covert channels and auditing of events.

 B3 − Allows creating lists or user groups for access-control to grant access or revoke
access to a given named object.

3
Type C

Provides protection and user accountability using audit capabilities. It is of two types.

 C1 − Incorporates controls so that users can protect their private information and keep
other users from accidentally reading / deleting their data. UNIX versions are mostly
Cl class.

 C2 − Adds an individual-level access control to the capabilities of a Cl level system.

4
Type D

Lowest level. Minimum protection. MS-DOS, Window 3.1 fall in this category.

You might also like