PERIYAR INSTITUTE OF DISTANCE EDUCATION

(PRIDE)

PERIYAR UNIVERSITY
SALEM - 636 011.

BACHELOR OF COMPUTER APPLICATIONS (BCA)

THIRD YEAR
PAPER – VIII : OPERATING SYSTEM

1
Prepared By
Prof. N. Rajendran M.C.A.,M.Phil.,
HOD of Computer Science,
Vivekanandha College of Arts
and Sciences for Women,
Elayampalayam,
Tiruchengode – 637 205.

2
 Forewords
Dear Students,
I welcome you to interesting part of Periyar University PRIDE distance
education. I am proud to present you the essential subject of computer science
which I call the soul of computers – The Operating System (OS). The
Operating System is one of the System Software which makes the Hardware
useable.
The first unit deals with Introduction, Evolution, Achievements, Process
description and Controls of OS.
The second unit deals with the concepts of Threads, Concurrency
control, various protocols, Semaphores, Deadlock conditions and preventions.
The Third unit introduces the concept of logical memory management
requirements, Partitioning, Paging, Segmentation, Virtual Memory and
Physical device structure.
The fourth unit deals with Uniprocessor Scheduling its types and
Algorithms, Multiprocessor Scheduling, Input/Output management and Disk
Scheduling.
The Fifth unit explains about Files, File Systems its Strunture,
Organization and Access, File Directories, File Sharing, Record Blocking and
Secondary Storage management.
The Periyar University PRIDE Distance education SIM pattern of this
booklet have been prepared and written by Prof. N. Rajendran, M.C.A.,
M.Phil., I expect that this booklet will help you to enrich your knowledge.

3
 OPERATING SYSTEM

BLOCK

UNIT I OPERATING SYSTEM OVERVIEW

UNIT II THREADS, CONCURRENCY

UNIT III MEMORY MANAGEMENT

UNIT IV UNIPROCESSOR SCHEDULING

UNIT V FILE MANAGEMENT

4
 BACHELOR OF COMPUTER APPLICATIONS
THIRD YEAR
PAPER – VIII : OPERATING SYSTEM
UNIT – I :
Operating System overview : Operating system objectives and functions
– Evaluation of O.S – Major achievements. Process Description and control :
Process – Process states – Process description and control.

UNIT – II :
Threads, Concurrency : Principles of concurrency – Mutual Exclusion –
Semaphores – Message Passing. Deadlock : Principles of deadlock – Deadlock
prevention – Deadlock avoidance – Deadlock detection.

UNIT – III :
Memory Management : Requirements – Memory partitioning – paging
– segmentation. Virtual memory : Hardware and control structures – Operating
system software.

UNIT – IV
Uniprocessor scheduling : Types of processor – Scheduling –
Scheduling algorithm – Multiprocess scheduling. I/O Management and Disk
scheduling : I/O Devices – Organization of the I/O function – I/O Buffering –
Disk scheduling.

UNIT – V
File Management : Overview – File organization & Access – File
Directories – File sharing – Record Blocking – Secondary storage management.
Case studies : Unix – Process Management, Memory Management, I/O
Management & File Management.

TEXT BOOK
“Operating Systems- Internals & Design Principles” William Stallings.
5th Edition
Prentice – Hall of India P. Ltd, New Delhi – 110 001.

5
UNIT I : OPERATING SYSTEM OVERVIEW

UNIT STRUCTURE

1.0 Operating System Overview

1.1 Objectives and functions
1.2 OS as resource manager – Efficiency
1.3 Evolution of OS – Maintainability
1.4 The evolution of operating systems
1.4.1 Serial processing
1.4.2 Simple batch systems
1.4.3 Multi programmed batch systems
1.4.4 Time-sharing system
1.5 Major Achievements of OS
1.5.1 Virtual Memory
1.6 Process Description and Control
1.6.1 THE PROCESS
1.6.2 PROCESS STATE
1.6.3 PROCESS CONTROL BLOCK

SELF ASSESSMENT QUESTIONS: I

Unit Questions
Recommendations for further readings
Answers of Self-Assessment Questions

6
1.0 Operating System Overview
Main purposes of an operating system
 To provide an environment for a computer user to execute programs on
computer hardware in a convenient and efficient manner.
 To allocate the separate resources of the computer as needed to solve
the problem given. The allocation process should be as fair and efficient
as possible.
 As a control program it serves two major functions:
(1) Supervision of the execution of user programs to
prevent errors and improper use of the computer.
(2) Management of the operation and control of I/O
devices.
1.1 Objectives and functions
OS as a user/computer interface – Usability
The reason for an operation system to exist is to make computers more
convenient to use. An OS aims to wrap the underneath hardware resources and
provides services to end users in a systematic way. These services may be
divided into two types: services directly available for end users through all
kinds of I/O devices, such as mouse, keyboard, monitor, printer, and so on; and
services for application programs, which in turn provides services for end
users. If we look on these services as interfaces among different components of
a computer system, then the following hierarchical architecture may be
obtained:
Users Programmer
| | |
v | |
+---------------+ | |
| Applications | v |
+-------------------------+ | OS designer
| Utilities | v |
+------------------------------+ |
| OS | V
+-----------------------------------+
| Hardware |
+-----------------------------------+
It is also common to consider Utilities and Applications that are
distributed together with an OS part of the OS, but obviously they are not
essential. Utilities are usually called libraries or APIs, providing frequently
used functions for the upper-level applications. From the point of view of end
users, a computer system consists of a variety of applications they may use. An

7
application is developed by programmers in a programming language. The
higher level the utilities are, the easier and more comfortable it is for
programmers to code in the corresponding programming language; or the
lower, the harder. In an extreme case, the assembly language is almost the same
as machine instructions except that mnemonic symbols are used to replace
binary strings or opcodes. In this kind of language, programmers have to deal
with an overwhelmingly complexity of manipulating computer hardware. On
the contrary, in a higher-level language, more user-friendly APIs are available,
e.g. opening a file by calling
open ("C:/filename.txt", "rw")
1.2 OS as resource manager – Efficiency
It is not the OS itself but the hardware that makes all kinds of services
possible and available to application programs. An OS merely exploits the
hardware to provide easily accessible interfaces. Exploitation means
management upon the hardware resources, and thus also imposes control upon
or manages the entities that use the services so that the resources are used
efficiently. In the classes later on, we will discuss this aspect, including process
scheduling, memory management, I/O device management, etc.
One thing worth mentioning here is that, different from other control systems
where the controlling facility, the controller, is distinct and external to the
controlled parts, the OS has to depend on the hardware resources it manages to
work.
+-------------------+
+------------+ | |
| | | Controlled |
| Controller | --------> | components |
| | | |
+------------+ +-------------------+
As we know, an OS is in nature a program, consisting instructions, thus
it also needs CPU to execute instructions so as to function as a controller, and
main memory to hold instructions for CPU to fetch. At the same time, the OS
has to be able to relinquish and regain later
the control of CPU so that other programs can get chance to run but still under
the control of the OS (An analogy to this is that an administrator of an
apartment building might live in the same building himself). By utilizing the
facilities provided by hardware, the OS may schedule different processes to run
at different moments and exchange the instructions and data of programs
between external storage devices, like hard disks, and main memory. These
topics will be covered as the course proceeds.
1.3 Evolution of OS – Maintainability
It does not suffice to simply consider an operating system an invariable
unit. An OS may evolve while time elapses due to the following reasons:

8
• Hardware upgrades or new types of hardware:
With hardware technologies development, the OS also needs to upgrade
so as to utilize the new mechanisms introduced by new hardware. For example,
Pentium IV extended instruction set of Pentium III for multimedia applications
and internet transmission. An OS designed for the previous versions of Intel
x86 series will have to be upgraded to be able to accommodate these new
instructions.
• New services:
An OS may also expand to include more services in response to user
demand.
• Fixes:
No software is perfect, and any program may contain more or less bugs
or defects, thus fixes should be made from time to time. Microsoft Windows is
a vivid example of this kind.
These situations all require OS designers to build an OS in the way that
the system can be maintained and upgraded easily. All the common software
design techniques may be applied to an OS, such as modularization. With
modularization, the OS is split into multiple modules with clearly defined
interfaces between them. Thus, as long as the interfaces are left untouched,
each single module may be upgraded independently.
1.4 The evolution of operating systems
To better understand the requirements for an operating system, it is
useful to consider how operating systems have evolved over the years.
1.4.1 Serial processing
The earliest computer system has no OS at all, and is characterized as
serial processing because users have to reserve time slots in advance, and
during the allotted period, they occupy the computer exclusively. Thus the
computer will be used in sequence by different users.
These early systems presented two major problems:
1. Users may finish their tasks earlier than you have expected, and
unfortunately the rest time is simply wasted. Or they may run into problems,
cannot finish in the allotted time, and thus are forced to stop, which causes
much inconvenience and delays the development.
2. In such systems, programs are presented by cards. Each card has several
locations on it, where there may be a hole or not, respectively indicating 0 or 1.
Programs are loaded into memory via a card reader. With no OS available, to
compile their programs, users have to manually load the compiler program first
with the user program as input. This involves mounting, or dismounting tapes
or setting up card decks. If an error occurred, the user has to repeat the whole
process from the very beginning. Thus much time is wasted.
1.4.2 Simple batch systems
To improve the utilization of computer systems, the concept of a batch
operating system was developed later on. The central idea is the use of a piece

9
of software known as the monitor. With it, users don’t have direct access to the
computer systems any longer; instead, the operator of the system collects the
user programs and batches them together sequentially for use by the monitor.
To process user programs, the monitor first has to be loaded into
memory. Then it reads in programs one at a time from the input devices. As
each program is read in, it will be placed in the user program area of main
memory, and control is passed to this program. When the execution of the
program is completed, it returns control to the monitor, which moves on to
process the next program.
To assist in this, a special language is used, called job control language
or JCL (At that time, each user program was called a job), which provides
instructions to the monitor. For example, the following is a FORTRAN
program with JCL commands.
$JOB $RUN
$PTN ...
... Data
FORTRAN instructions ...
... $END
$JOB indicates the beginning of a job. $FTN tells the monitor to load
the FORTRAN compiler, which generates object code from the FORTRAN
source program. The monitor regains control after the compile operation.
$RUN makes control transferred from the monitor to the current program,
which works on the data following until a successful or unsuccessful
completion. The monitor then may move on to another job. To much extent,
JCL instructions are similar to the command sequence in a DOS batch file or a
UNIX shell file. The latters tell the operating systems to run multiple
commands automatically.
The advantage of this mode is that the monitor automates the execution
of multiple jobs thus much time is saved by avoiding manual operations.
1.4.3 Multi programmed batch systems
Even with the automatic job processing by a monitor, the processor is
still often idle. The problem is actually what we have discussed before
regarding programmed I/O. That is a program may have to wait for I/O
operation to finish and thus leads to the processor’s idling. The solution is to
run multiple programs concurrently during a certain period so that whenever
the current program has to wait for I/O devices, control may be transferred to
another program. If needed, a third program may be loaded, or even more. This
scheme is called multiprogramming or multitasking. With multiprogramming,
the utilization of processor is greatly improved, but it has its own problems. To
run multiple programs concurrently, the memory should be organized properly
so that each program has its own space and does not invade others’. What’s
more, at some moment, there may be more than programs ready to run. Thus
some form of scheduling is needed to obtain better performance.

10
1.4.4 Time-sharing system
With multiprogramming, the overall system is quite efficient. However
a problem remains. That is those jobs that come late in the batch job list won’t
get chance to run until the jobs before them have completed, thus their users
have to wait a long time to obtain the results. Some programs may even need
interaction with users, which requires the processor to switch to these programs
frequently. To reach this new goal, a similar technique to multiprogramming
can be used, called time sharing. In such a system, multiple users
simultaneously access the system through terminals, with the operating system
interleaving the execution of each user program in a short burst of computation.
For example, suppose a computer system may have at most 10 uses at the same
time, and the human reaction time is 200 ms. Then we may assign 200/10 =
20ms CPU time to the user programs one by one in a cyclic manner, thus each
user will be responded within the human reaction time so that the computer
system seems to service the user program itself.
1.5 Major Achievements of OS
In the very early days of computing, a computer was a single task,
single user machine. A user would load their program in source code from
punch cards or punch tape, load an appropriate compiler, any required
libraries, an assembler or linker, etc, compile the program and run it. This
was a very time consuming and error prone process. Since computers were very
expensive machines any idle time was a major cost to the computers operator.
Batch systems were introduced with the intention of reducing the setup and tear
down time involved with running a program. In a batch system, similar
programs would be put in batches. For example, all programs which required
the FORTRAN compiler would be batched together. The computer would be
set up appropriately and all programs in the batch were run in sequential order.
This in itself was a major change from the way the user interacted with a
computer. No longer were they required to set up the computer for operation,
but now they submitted their jobs to a job manager who took responsibility for
running the jobs. Even though batch processing had some performance gains,
the computer still remained a single task machine. Once a job was submitted it
had access to all the resources on the computer and had to take its own
responsibility for managing them. When programs were analyzed, it was
realized that much of a programs time is spent doing I/O operations between
the processor and disk or printer for example. Up to 96% of programs
execution time has the central processing unit (CPU) idle while I/O is taking
place. The solution to this was to interleave programs on the processor. Thus
the Multi programmed Batch System was born. In this arrangement if Program
A requested an I/O operation Program B could be loaded to use the processor
until it blocked for I/O or completed, then Program A could resume operation.
This could be taken to the nth degree dependent on system memory size etc., as
all programs had to be loaded into memory simultaneously to make use of this
switching. With multiple programs in memory some sort of memory
management function was needed. Also with the possibility of multiple

11
programs being read to run at the same time, some program scheduling
function was required. These were addressed in the first rudimentary operating
system, a program written with the intention of controlling and managing other
programs. Even to this day, memory management and process scheduling are
among the corner stones of all modern operating systems.
1.5.1 Virtual Memory
In early computers, instructions were read one by one from punch cards
or punch tape as they were needed. When stored program computers came
along, they kept the same metaphor, though now the next instruction to execute
was stored in memory and not on a punched card. Just like punched cards had
to be kept in sequence so did the instructions in memory, and programs were
loaded into contiguous memory locations for execution. With the advent of
Multi programmed Batch Systems were several programs could be in memory
at the same time, computer designers were tasked with keeping the CPU busy
as much of the time as possible. However they were restricted in this as they
could only load so many programs as the computers memory could
accommodate. If the situation arose where all loaded programs were waiting
for I/O, then it would be useful if the system could unload one of the programs
and load another to make use of the CPU. In essence a swap system was
needed. This leads to the development of sophisticated memory management.
1.6 Process Description and Control
1.6.1 THE PROCESS
A process is a program in execution. A process is more than a program
code, which is sometimes known as the text section. It also includes the current
activity, as represented by the value of the program counter and the contents
of the processor’s registers. A process generally also includes the process
stack, which contains temporary data (such as function parameters, return
address, and local variables), and a data section, which contains global
variables. A process may also include a heap, which is memory that is
dynamically allocated during process run time. The structure of the process in
memory is shown in the following figure.

12
 stack

heap

data

text

Process in memory
We emphasize that a program by itself is not a process; a program is a
passive entity, such as a file containing a list of instructions stored on disk
(often called an executable file), whereas as a process is an active entity, with a
program counter specifying the next instruction to execute and set of associated
resources. A program becomes a process when an executable file is loaded into
memory. Two common techniques for loading executable files are double-
clicking an icon representing the executable file and entering the name of the
executable file on the command line.
Although two processes may be associated with the same program, they
are nevertheless considered two separate execution sequences. For instance,
several users may be running different copies of the mail program, or the same
user may invoke many copies of the web browser program. Each of these is a
separate process; and although the text sections are equivalent, the data, heap,
and stack sections vary. It is also common to have a process that spawns many
processes as it runs.
1.6.2 PROCESS STATE
As a process executes, it changes state. The state of process is defined
in many parts by the current activity of that process. Each process may be in
one of the following states:
 New. The process is being created.
 Running. Instructions are being executed.
 Waiting. The process is waiting for some event to occur (such as I/O
completion or reception of a signal).
 Ready. The process is waiting to be assigned to a processor.
 Terminated. The process has finished execution.
These names are arbitrary, and they vary across operating systems. The
states that they represent are found on all systems, however. Certain operating
systems also more finely delineate process states. It is important to realize that

13
only one process can be running on any processor at any instant. Many
processes may be ready and waiting, however. The state diagram
corresponding to these is presented in the following figure.

terminated
new

ready running

waiting

Diagram of Process State

1.6.3 PROCESS CONTROL BLOCK
Each process is represented in the operating system by a process
control block (PCB)-also called a task control block. A PCB is shown in the
figure. It contains many pieces of information associated with a specific
process, including these:
process state

process number

program counter

registers

Memory limits

List of open files

...
Process control block (PCB)

14
  Process state. The state may be new, ready, running, and waiting,
halted, and so on.
 Program counter. The counter indicates the address of the next
instruction to be executed for this process.
 CPU registers. The registers vary in number and types, depending on
the computer architecture. They include accumulators, index registers,
stack pointers, and general-purpose registers, plus any condition-code
information. Along with the program counter, this state information
must be saved when an interrupt occurs, to allow the process to be
continued correctly afterward.
 CPU-scheduling information. This information includes a process
priority, pointers to scheduling queues, and other scheduling
parameters.
 Memory–management information. This information may include
such information as the value of the base and limit register, the page
tables, or the segment tables, depending on the memory system used by
the operating system.
 Accounting information. This information includes the amount of
CPU and real time used, time limits, account numbers, job or process
numbers, and so on.
 I/O status information. This information includes the list of I/O
devices allocated to the process, a list of open files, and so on.
In brief, the PCB simply serves as the repository for any information that may
vary from process to process.

SELF-ASSESSMENT QUESTIONS: I

ANSWER THE FOLLOWING QUESTIONS

1. What is an operating system?

---------------------------------------------

2. What is a Process?
---------------------------------------------

3. In early computers, instructions were read one by one from

__________
or punch tape as they were needed.

15
UNIT QUESTIONS
1. Define an operating system?
2. Explain the salient features of operating system.
3. Explain the evolution of OS.
4. Describe the major achievements of OS in detail.
5. Discuss: Process description and control.
RECOMMENDATIONS FOR FURTHER READING
1. Operating Systems – A Modern Perspective, Gary Nutt, Pearson
Education Asia, Second Edition.
2. Operating Systems – Internals and Design Principles, William
Stallings, Pearson Education, Fifth Edition.
3. Operating Systems – Internals and Design Principles, William
Stallings, Eastern Economy Edition, Fifth Edition.
ANSWERS OF SELF-ASSESSMENT QUESTIONS
1. An operating system is used to provide an environment for a computer
user to execute programs on computer hardware in a convenient and
efficient manner.
2. A process is a program in execution. A process is more than a program
code, which is sometimes known as the text section. It also includes the
current activity, as represented by the value of the program counter
and the contents of the processor’s registers.
3. Punch Cards.

16
 NOTES
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..

17
 UNIT II : THREADS AND CONCURRENCY

UNIT STRUCTURE

2.0 THREADS
2.1 A PROCESS AND ITS ASSOCIATED THREADS
2.2 CONCURRENCY CONTROL
2.3 LOCKING PROTOCOLS
2.4 MAJORITY PROTOCOL
2.5 BIASED PROTOCOL
2.6 SEMAPHORES
2.7 DEADLOCKS
2.7.1 DEADLOCK CHARACTERIZATION
2.7.2 DEADLOCK PREVENTION
2.7.3 DEADLOCK AVOIDANCE
2.7.4 DEADLOCK DETECTION

SELF-ASSESMENT QUESTIONS: I

UNIT QUESTIONS
RECOMMENDATIONS FOR FURTHER READING
ANSWER OF SELF-ASSESSMENT

18
 UNIT II : THREADS AND CONCURRENCY

2.0 THREADS
The motivation for the thread model is to create a simple OS abstraction
where there can be multiple entries that execute the same program, using the
same files and derives. A thread is an alternative form of schedulable unit of
computation to the traditional notion of process. In the thread model of
computation, the process is an abstraction that can be allocated various
resources, yet which has no component that can execute programs. A thread is
an entity that executes using the program and other resources of its associated
process. There can be several threads associated with the single process.
Sibling threads-threads associated with the same process-share the program and
resource of the process. The threads must have a minimum of its own allocated
resources so that its internal state is not confused with the internal state of other
threads associated with the same process. As a practical matter, these minimum
resources are a stack, a portion of the traditional process’s status information,
and some OS table entries. In a thread model the normal notion of process
corresponds to a passive resource with a single active thread to carry out
program execution.

Threads

Data

Threads status

Program Data
Text Resource

Process Status

Heavyweight process
2.1 A Process and Its Associated Threads
A thread scheduler, analogous to the process scheduler in the more
traditional model, switches the processor among a set of competing threads. In
some systems, the thread scheduler is a user program and in others it is part of
OS. Since threads have little state, the thread scheduler has less work to do
when actually switching from one thread to another than is required for
switching processes. Hence, an important motivation for using threads is to
minimize context switching time. This allows the processor to switch from one

19
unit of computation with minimal overhead. Even so, the thread manager
requires a descriptor to save each thread’s register and stack contents.
Threads are an especially useful programming model when several
different units of computation need to utilize shared but logically distinct
facilities. The shared facility is managed by a community of threads that is
defined by a common process. Threads have become very popular for certain
classes of distributed applications. Contemporary window system often uses
the thread paradigm for managing virtual terminal sessions in the context of the
physical terminal. Suppose a window system is built with a heavyweight
physical screen manager, with several related virtual screen threads. All threads
run the same code, and all share the physical screen, yet each thread manages
just one window in the collection of windows. Response time is very important
in this type of system, so context switching among individual virtual screen
managers is important. Threads are an ideal mechanism for implementing such
a system and are widely used in commercial windowing systems.
Today, threads are an important tool in the repertoire of the concurrent
programmer. A thread executes within the address space of a process but as an
independent unit of computation. In this sense, a thread is like a process
managed by the FORK/JOIN/QUIT primitive described. This means that a
scheduler can control the progress of each thread in a community of threads.
However, threads share the resources allocated to the “mother ship” process-
threads always exist within the context of the process. Furthermore, a set of
threads associated with a process use the same address space as the process, so
the thread siblings execute the same process use the same programs using the
same resources and data. Threads are a way to refine and divide the work
normally associated with a process.
2.2 CONCURRENCY CONTROL
The transaction manager of a distributed database system manages the
execution of those transaction (or sub transactions) that access data stored in a
local site. Each such transaction may be either a local transaction (that is, a
transaction that executes only at that site) or part of a global transaction (that is,
a transaction that executes at several sites). Each transaction manager is
responsible for maintaining a log for recovery purposes and for participating in
an appropriate concurrency-control scheme to coordinate the concurrent
execution of the transaction executing at that site.
2.3 LOCKING PROTOCOLS
The two-phase locking protocols can be used in a distributed
environment. The only change needed is in the way the lock manager is
implemented.
NONREPLICATED SCHEME
If no data are replicated in the system, then the locking scheme can be
applied as follows: Each site maintains a local lock manager whose function is
to administer the lock and unlock requests for those data items stored in that
site. When a transaction wishes to lock data item Q at site Si, it simply sends a

20
message to the lock manager at site Si requesting a lock. If data item Q is
locked in an incompatible mode, then the request is delayed until that request
can be granted. Once it has been determined that the lock request can be
granted, the lock manager sends a message back to the initiator indicating that
the lock request has been granted.
SINGLE-COORDINATOR APPROACH
Several concurrency-control schemes can be used in system that allows
data replication. Under the single-coordinator approach, the system maintains a
single lock manager that resides in a single chosen site-say, Si. All lock and
unlock requests are made at site Si. When a transaction needs to lock a data
item, it sends a lock requests to Si. The lock manager determines whether the
lock can be granted immediately. If so, it sends a message to that effect to the
site at which the lock request was initiated. Otherwise, the request is delayed
until it can be granted; and at that time, a message is sent to the site at which
one of the site at which a replica of the data item resides. In the case of a write
operation, all the sites where a replica of the data item resides must be involved
in the writing.
The scheme has the following advantages:
 Simple implementation. This scheme requires two messages for
handling lock request and one message for handling unlock requests.
 Simple deadlock handling. Since all lock and unlock requests are
made at one site, the deadlock-handling algorithms can be applied
directly to this environment.
The disadvantages of the scheme include the following:
 Bottleneck. The site Si becomes a bottleneck, since all requests must be
processed there.
 Vulnerability. If the site Si fails, the concurrency controller is lost.
Either processing must stop or a recovery scheme must be used.
2.4 MAJORITY PROTOCOL
The majority protocol is a modification of the no replicated data
scheme. The system maintains a lock manager at each site. Each manager
controls the locks for all the data or replicas of data stored at that site. When a
transaction wishes to lock a data item Q that is replicated in n different sites, it
must send a lock requests to more than one-half of the n sites in which Q is
stored. Each lock manager determines whether the lock can be granted
immediately.
This scheme deals with replicated data in a decentralized manner, thus
avoiding the drawbacks of central control. However, it suffers from its own
disadvantages:
 Implementation. The majority protocol is more complicated to
implement than the previous schemes. It requires 2(n/2+1) messages for
handling lock requests and (n/2+1) messages for handling unlock
requests.

21
  Deadlock handling. Since the lock and unlock requests are not made at
one site, the deadlock-handling algorithms must be modified. In
addition, a deadlock can occur even if only one data item is being
locked.
2.5 BIASED PROTOCOL
The biased protocol is similar to the majority protocol. The difference is
that requests for shared locks are given more favorable treatment than are
requests for exclusive locks. The system maintains a lock manager at each site.
Each manager the locks for the data items stored at the site. Shared and
exclusive locks are handled differently.
 Shared locks. When a transaction needs to lock data item Q, it simply
requests a lock on Q from the lock manager at one site containing a
replica of ch18/18.
 Exclusive locks. When a transaction needs to lock data item Q, it
requests a lock on Q from the lock manager at each site containing a
replica of ch18/18.
PRIMARYCOPY
Yet another alternative is to choose one of the replicas as the primary
copy. Thus, for each data item Q, the primary copy of Q must reside in
precisely one site, which we call the primary site of Q. When a transaction
needs to lock a data item Q, it requests a lock at the primary site of ch18/18. As
before, the response to the request is delayed until the request can be granted.
This scheme enables us to handle concurrency control for replicated
data in much the same way as for unreplicated data. Implementation of the
method is simple. However, if the primary site of Q fails, Q is inaccessible
even though other sites containing a replica may be accessible.
TIMESTAMPING
The principal idea behind the time stamping scheme is that each
transaction is given a unique timestamp, which is used to decide the
serialization order.
GENERATION OF UNIQUE TIMESTAMPS
Two primary methods are used to generate unique timestamps; one is
centralized, and one is distributed. In the centralized scheme, a single site is
chosen for distributing the timestamps. The site can use a logical counter or its
own local clock for this purpose.
In the distributed scheme, each site generates a local unique timestamp
using either a logical counter or the local clock. The global unique timestamp is
obtained by concatenation of the local unique timestamp with the site identifier,
which must be unique. The order of concatenation is important! We use the site
identifier in the least significant position to ensure that the global timestamps
generated in one site are not always greater than those generated in another site.

22
 local unique timestamp site identifier

global unique identifier

Generation of unique timestamps
2.6 SEMAPHORES
The various hardware-based solution to the critical-section problem
(using the TestAndSet ( ) and Swap ( ) instructions) presented in this section
are complicated for application programmers it use. To overcome this
difficulty, we can use a synchronization tool called a semaphore.
A semaphore S is an integer variable that, apart from initialization, is
accessed only through two standard atomic operations: wait ( ) and signal ( ).
The wait ( ) operation was originally termed P ; signal( ) was originally called
V is as follows:
wait (S) {
while S <= 0
; // no-op
S--;
}
The definition of signal ( ) is as follows:
signal (S) {
S++;
}
All the modifications to the integer value of the semaphore in the wait (
) and signal ( ) operations must be executed indivisibly. That is, when one
process modifies the semaphore value, no other process can simultaneously
modify that same semaphore value. In addition, in the case of wait(S), the
testing of the integer value of S (S<=0), and its possible modification (S--),
must also be executed without interruption.
2.7 DEADLOCKS
In the multiprogramming environment, several processes may compete
for a finite number of resources. A process requests resources; and if the

23
resources are not available at that time, the process enters a waiting state.
Sometimes, a waiting process is never again able to change state, because the
resources it has requested are held by other waiting processes. This situation is
called a deadlock.
2.7.1 DEADLOCK CHARACTERIZATION
In the deadlock, processes never finish executing, and system resources
are tied up, preventing other jobs from starting. Before we discuss the various
methods for dealing with the deadlock problem, we look more closely at
features that characterize deadlocks.
Necessary Conditions
A deadlock situation can arise if the following four conditions hold
simultaneously in a system:
1. Mutual exclusion. At least one resource must be held in a non-sharable
mode; that is, only one process at a time can use the resource. If another
process requests that resource, the requesting process must be delayed until the
resource has been released.
2. Hold and wait. A process must be holding at least one resource and waiting
to acquire additional resources that are currently being held by other processes.
3. No preemption. Resources cannot be preempted; that is, a resource can be
released only voluntarily by the process holding it, after that process has
completed its task.
4. Circular wait. A set {P0,P1,…,Pn} of waiting processes must exist such that
P0 is waiting for a resource held by P1, P1 is waiting for a resource held by
P2,…,Pn-1 is waiting for a resource held by Pn, and Pn is waiting for a resource
held by P0.
2.7.2 DEADLOCK PREVENTION
For a deadlock to occur, each of the four necessary conditions must
hold. By ensuring that at least one of these conditions cannot hold, we can
prevent the occurrence of a deadlock. We elaborate on this approach by
examining each of the four necessary conditions separately.
Mutual Exclusion
The mutual-exclusion condition must hold for non-sharable resources.
For example, a printer cannot be simultaneously shared by several processes.
Sharable resources, in contrast, do not require mutually exclusive access and
thus cannot be involved in a deadlock. Read-only files are a good example of
same time, they can be granted simultaneous access to the file. A process never
needs to wait for a sharable resource. In general, however, we cannot prevent
deadlocks by denying the mutual-exclusion condition, because some resources
are intrinsically non-sharable.
Hold and Wait
To ensure that the hold-and-wait condition never occurs in the system,
we must guarantee that, whenever a process requests a resource, it dose not
hold any other resources. One protocol that can be used requires each process

24
to request and be allocated all its resources before it begins execution. We can
implement this provision by requiring that system calls requesting resources for
a process precede all other system calls.
An alternative protocol allows a process to request resources only when
it has none. A process may request some resources and use them. Before it can
request any additional resources, however, it must release all the resources that
it is currently allocated.
No Preemption
The third necessary condition for deadlocks is that there is no
preemption of resources that have already been allocated. To ensure that this
condition dose not holds, we can use the following protocol. If a process is
holding some resources and requests another resource that cannot be
immediately allocated to it (that is, the process must wait), then all resources
currently being held are preempted. In other words, these resources are
implicitly released. The preempted resources are added to the list of resources
for which the process is waiting. The process will be restarted only when it can
regain its old resources, as well as the new ones that it is requesting.
2.7.3 DEADLOCK AVOIDANCE
An alternative method for avoiding deadlocks is to require additional
information about how resources are to requested. For example, in a system
with one tape drive and one printer, the system might need to know that process
P will request first the tape drive and then the printer before releasing both
resources, whereas process Q will request first the printer and then the tape
drive. With this knowledge of the complete sequence of request and releases
for each process, the system can decide for each request whether or not the
process should wait in order to avoid a possible future deadlock.
The various algorithms that use this approach differ in the amount and
type of information required. The simplest and most useful model requires that
each process declare the maximum number of resources of each type that it
may need. Given this a priori information, it is possible to construct an
algorithm that ensures that the system will never enter a deadlock state. Such
an algorithm defines the deadlock-avoidance approach. A deadlock-avoidance
algorithm dynamically examines the resource-allocation state to ensure that a
circular-wait condition can never exist. The resources-allocation state is
defined by the number of available and allocated resources and the maximum
demands of the process.
SAFE STATES
A state is safe if the system can allocate resources to each process (up to
its maximum) in some order and still avoid a deadlock. More formally, a
system is in a safe state only if there exists a safe sequence. A sequence of
processes <P1,P2 ……Pn> is a safe sequence for the current allocation state if,
for each Pi , the resource request that Pi can still make can be satisfied by the
currently available resource plus the resources held by all Pj , with j<i. In this
situation, if the resources that Pi needs are not immediately available, then Pi

25
can wait until all Pj have finished. When they have finished, Pi can obtain all of
its needed resources, complete its designated task, return its allocated
resources, and so on. If no such sequence exists, then the system state is said to
be unsafe.
A safe state is not a deadlocked state. Conversely, a deadlocked state is
an unsafe state. Not all unsafe states are deadlocks, however. An unsafe state
may lead to a deadlock. As long as the state is safe, the operating system can
avoid unsafe (and deadlocked) States. In an unsafe state the operating system
cannot prevent processes from requesting resources such that a deadlock
occurs.

Unsafe

deadlock

safe

RESOURCE-ALOCATION-GRAPH ALGORITHM:
If we have a resource-allocation system with only one instance of each
resource type, a variant of the resource-allocation graph defined. It can be used
for deadlock avoidance. In addition to the request and assignment edges
already described, we introduce a new type of edge, called a claim edge. A
claim edge Pi Rj indicates that process Pi may request resource Rj at some
time in the future. This edge resembles a request edge in direction but is
represented in the graph by a dashed line. When process Pi requests resource Rj
, the claim edge Pi  Rj is converted to a request edge. Similarly, when a
resource Rj is released by Pi , the assignment edge Rj Pi is reconverted to a
claim edge Pi  Rj.
BANKER’S ALGORITHM
The resource-allocation-graph algorithm is not applicable to a resource-
allocation system with multiple instances of each resource type. The deadlock-
avoidance algorithm that is applicable to such a system but is less efficient than
the resource-allocation graph scheme. This algorithm is commonly known as
the banker’s algorithm. The name was chosen because the algorithm could be
used in a banking system to ensure that the bank never allocated its available
cash in such a way that it could no longer satisfy the needs of all its customers.

26
 When a new process enters the system, it must be declare the maximum
number of instances of each resource type that it may need. This number may
not exceed the total number of resources in the system.
Let n be the number of processes in the system and m be the number of
resource types. We need the following data structures:
 Available. A vector of length m indicates the number of available
resources of each type. If Available[j] equals k, there are k instances of
resource type Rj available.
 Max. An n x m matrix defines the number of resources of each process.
If Max[i][j] equals k, then process Pi may request at most k instances of
resource type R j.
 Allocation. An n x m matrix defines the number of resources of each
type currently allocated to each process. If Allocation[i][j] equals k,
then process Pi is currently allocated k instances of resource type Rj.
 Need. An n x m matrix indicates the remaining resource need of each
process. If Need[i][j] equals k, then process Pi may need k more
instances of resource type Rj to complete its task. Note that Need[i][j]
equals Max[i][j]-Allocation[i][j].
These data structures vary over time in both size and value.
2.7.4 DEADLOCK DETECTION
If a system does not employ either a deadlock –prevention or a
deadlock avoidance algorithm, then a deadlock situation may occur. In this
environment, the system must provide:
 An algorithm must examine the state of the system to determine
whether a deadlock has occurred.
 An algorithm to recover from the deadlock.
In the following discussion, we elaborate on these two requirements, as they
pertain to systems with only a single instance of each resource type, as well as
to systems with several instances each resource type. At this point, however,
we note that a detection-and-recovery scheme requires to overhead that
includes not only the run-time costs of maintaining the necessary information
and executing the detection algorithm but also the potential losses inherent in
recovering from a deadlock.
Single Instance of Each Resource Type
If all resources have only a single instance, then we can define a
deadlock-detection algorithm that uses a variant of the resource-allocation
graph, called a wait-for graph. We obtain this graph from the resource-
allocation graph by removing the resource nodes and collapsing the appropriate
edges.
More precisely, an edge from Pi to Pj in the wait-for graph implies that
process Pi is waiting for the process Pj to release a resource that Pi needs. An
edge Pi  Pj exits in a wait-for graph if and only if the corresponding resource-

27
allocation graph contains two edges Pi  Rq and Rq  Pi for some resource Rq.
For example, in figure, we present a resource-allocation graph and the
corresponding wait-for graph.
As before, a deadlock exists in the system if and only if the wait-for
graph contains a cycle. To detect deadlocks, the system needs to maintain the
wait-for graph and periodically invoke an algorithm that searches for a cycle in
the graph requires an order of n2 operations, where n is the number of vertices
in the graph.
Several Instances of a Resource Type
The wait-for graph scheme is not applicable to a resource-allocation
system with multiple instances of each resource type. We turn to a deadlock-
detection algorithm that is applicable to such a system. The algorithm employs
several time-varying data structures that are similar to those used in the
banker’s algorithm.
 Available. A vector of length m is indicates the number of available
resources of each type.
 Allocation. An n x m matrix defines the number of resources of each
type currently allocated to each process.
 Request. An n x m matrix indicates the current request of each process.
If Request[i][j] equals k, then process Pi is requesting k more instances
of resource type Rj.
The <= relation between two vectors is defined in this section. To simplify
notation, we again treat as Allocation and Request as vectors; we refer to
them as Allocationi and requesti . the detection algorithm describes here
simply investigates every possible allocation sequence for the processes
that remain to be completed. Compare this algorithm sequence for the
processes that remain to be completed.
1. Let Work and Finish be vectors of length m and n, respectively.
Initialize Work = Available. For i =0, 1, …, n-1,if Allocation =/
0,then Finish[i] = false; otherwise, Finish[i] = true.
2. Find an index I such that both
a. Finish[i] == false
b. Requesti <= Work
If no such I exists, goto step 4.
3. Work = Work + Allocationi
Finish[i] = true
Go to step 2.
4. If Finish[i] == false, for some i, 0<=i<n, then the system is in a
deadlocked state. Moreover, if Finish[i] == false, then process Pi
is deadlocked.
This algorithm requires an order of m x n2 operations to detect whether
the system is in a deadlocked state.

28
 We have an optimistic attitude and assume that Pi will require no more
resources to complete its task; it will thus soon return all currently allocated
resources to the system. If our assumption is incorrect, a deadlock may occur
later. That deadlock will be detected the next time the deadlock will be detected
the next time the deadlock-detection algorithm is invoked.
To illustrate this algorithm, we consider a system with five process P0
through P4 and three resource types A, B, and C. Resource type A has seven
instances, resource type B has two instances, and resource type C has six
instances. Suppose that, at time T0, we have the following resource-allocation
state:
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
We claim that the system is not a deadlocked state. Indeed, if we
execute our algorithm, we find that the sequence < P0, P2, P3, P1, P4> result in
Finish[i] == true for all i.
Suppose now that process p2 makes one additional request for an
instance of type C .The Request matrix is modified as follows:
Request
ABC
P0 000
P1 202
P2 001
P3 100
P4 002
We claim that the system is now deadlocked. Although we can reclaim
the resources held by process P0, the number of available resources is not
sufficient to fulfill the requests of the other processes. Thus, a deadlock exists,
consisting of processes P1,P2,P3 & P4.
DETECTION-ALGORITHM USAGE
When should be invoke the detection algorithm? The answer depends
on two factors:
1. How often is a deadlock likely to occur?
2. How many processes will be affected by deadlock when it happens?

If deadlocks occur frequently, then the detection algorithm should be

invoked frequently. Resources allocated to a deadlock processes will be idle

29
until the deadlock can be broken. In addition, the number of processes involved
in the deadlock cycle may grow.
Deadlocks occur only when some process makes a request that cannot
be granted immediately. This request may be the final request that completes a
chain of waiting processes. In the extreme, we can invoke the deadlock-
detection algorithm every time a request for allocation cannot be granted
immediately. In this case, we can identify not only the deadlocked set of
processes but also the specific process that “caused” the deadlock.(In reality,
each of the deadlocked processes is a link in the cycle in the resource graph, so
all of them, jointly, causes the deadlock.)If there are many different resource
types, one request may create many cycles in the resource graph, each cycle
completed by the most recent request and “cause” by the one identifiable
process.
Of course, if the deadlock-detection algorithm is invoked for every
resource request, this will incur a considerable overhead in computation time.A
less expensive alternative a simply to invoke the algorithm at less frequent
intervals-foe example, once per hour or whenever CPU utilization drops below
40 percent.(A deadlock eventually cripples system throughput & causes CPU
utilization to drop). If the detection algorithm at arbitrary points in time, there
may be many cycles in the resource graph. In this case we would generally not
be able to tell which of the many deadlocked processes “caused” the deadlock.
SELF-ASSESSMENT QUESTIONS: I

ANSWER THE FOLLOWING QUESTIONS

1. What is a thread?
---------------------------------------------

2. What is Concurrency Control?

---------------------------------------------

3. An alternative method for avoiding deadlocks is to require

______________ about how resources are too requested.

UNIT QUESTIONS
1. Define a thread.
2. What is concurrency control?
3. Explain about Semaphores.
4. What are the principles of dead lock?
5. Describe elaborately the concept of Dead Locks.

30
RECOMMENDATIONS FOR FURTHER READING
1. Operating Systems – A Modern Perspective, Gary Nutt, Pearson
Education Asia, Second Edition.
2. Operating Systems – Internals and Design Principles, William Stallings,
Pearson Education, Fifth Edition.
3. Operating Systems – Internals and Design Principles, William Stallings,
Eastern Economy Edition, Fifth Edition.

ANSWERS OF SELF-ASSESSMENT QUESTIONS

1. The motivation for the thread model is to create a simple OS abstraction

where there can be multiple entries that execute the same program,
using the same files and derives.
2. The transaction manager of a distributed database system manages the
execution of those transaction (or sub transactions) that access data
stored in a local site.
3. Additional Information.

31
 NOTES
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..

32
 UNIT III : MEMORY MANAGEMENT

UNIT STRUCTURES

3.1 MEMORY MANAGEMENT REQUIREMENTS

3.1.1 ADDRESS MAPPING AND RELOCATION
3.1.2 PROTECTION AND SHARING
3.1.3 APPLICATION ORGANIZATION
3.1.4 TWO-LEVEL MEMORY ORGANIZATION
3.2 MEMORY PARTITIONING
3.2.1 FIXED PARTITIONING
3.2.2 DYNAMIC PARTITIONING
3.3 PAGING
3.3.1 PAGES AND FRAMES
3.3.2 PAGE TABLE AND ADDRESS TRANSLATION
3.3.3 HARDWARE SUPPORT
3.4 SEGMENTATION
3.5 VIRTUAL MEMORY
3.5.1 SEGMENTED MEMORY MANAGEMENT
3.5.2 PAGED MEMORY MANAGEMENT
3.6 HARDWARE AND CONTROL STRUCTURES
3.7 HARDWARE AND CONTROL STRUCTURES
3.7.1 COMPUTERS AND SOFTWARES
3.7.2 GENERAL SYSTEM SOFTWARE
3.7.3 COMPUTERS WITHOUT SYSTEM SOFTWARE
SELF-ASSESMENT QUESTIONS: I
UNIT QUESTIONS
RECOMMENDATION FOR FURTHER READINGS
ANSWERS OF SELF-ASSESMENT QUESTIONS

33
 UNIT III : MEMORY MANAGEMENT

Main memory is a very important component in a computer system

because both the operating system and various user applications have to be
loaded into main memory first before being able to be executed. The efficiency
of memory management to much extent affects the efficiency of the whole
system. This part first explores the requirements for memory management and
then various approaches are introduced.
3.1 Memory management requirements
By examining the nature of the execution of programs, the following
requirements are to be satisfied.
3.1.1 Address mapping and relocation
After a process is created and loaded into main memory, it is ready to
run. For the operating system to dispatch it, the following information must be
known for access, as shown in the following Figure.
The locations of process control information, the execution stack, and
code entry. However these are not enough. Within a program, there may be
also memory references in various instructions, e.g. jump somewhere, where
somewhere is a reference to a memory location which contains the next
instruction to be executed, or move AX, [somewhere else], where somewhere
else is the memory location in which the value is supposed to be moved into
AX. Before the program is loaded, these references are usually the relative
addresses to the entry point of the program, which is 0. These addresses are
also called logical addresses, which make up a logical address space. After the
loading of the program to a location in the main memory, some facility must be
available to support transforming the logical addresses into physical addresses,
which are the real addresses of main memory pointing to destination data or
instructions and makes up the physical address space. Thus somehow the
processor and the operating system must be able to translate logical addresses
into physical ones, reflecting the current location of the program, as shown in
the following Figure.
The translation may be performed in different ways at different
moments, as follows:
• Compiler time:
If it is known in advance that a program will reside at a specific location
of main memory, then the compiler may be told to build the object code with
absolute addresses right away. For example, the boot sect in a bootable disk
may be compiled with the starting point of code set to 007C:0000.
• Load time:
It is pretty rare that we know the location a program will be assigned
ahead of its execution. In most cases, the compiler must generate relocatable
code with logical addresses. Thus the address translation may be performed on
the code during load time. The following figure shows that a program is loaded

34
 at location x. If the whole program resides on a monolithic block, then every
memory reference may be translated to be physical by added to x.
Main
memory
library

Module1

linker
Load loader
Module2 module

Module n

A loading scenario
• Execution time:
The load-time translation can solve the problem in some sense, however
in some cases; a process has to be moved from one location to another during
execution. For example, a process may be swapped out to virtual memory area
in the disk so that another process may be loaded. When it is swapped back into
the main memory, it is painful to require that it resides at the previous location,
since the location may still be occupied by another process. Thus the process
needs to be relocatable. In this case, the translation is done dynamically during
the execution time: Easy memory reference remains to be logical, and when it
is to be involved in the execution, the translation facility works on it and
generate the physical address. Note that the generated address does not replace
the original logical address one. Most general-purpose operating systems use
this method.
3.1.2 Protection and sharing
Memory references are valid if pointing to locations that belong to the
current process itself, however usually prohibited if referring to locations in
other processes, whether accidental or intentional. Note that the memory
protection requirement needs help from the processor rather than the operating
system, since when a process occupies the processor, the operating system can
hardly control it; say checking the validity of memory references. Any
protection mechanism must allow several processes to access the same portion

35
of main memory. For example, multiple processes may use a same system
library and it is natural to load one copy of the library in main memory and let
it shared by those processes.
3.1.3 Application organization
As we know, main memory is organized as a linear, or one-
dimensional, address space, while most programs are organized into modules.
Whether regarding sharing or protection, it is natural for the users to express
control in terms of modules, thus some supporting mechanism is needed. The
segmentation method we will cover later on responds to this requirement.
3.1.4 Two-level Memory organization
We have discussed memory hierarchy which includes both fast
expensive memories and slow but cheap storage devices. Typically two levels
of storage are present, main memory and disks. The former is fast, but usually
cannot provide enough space for concurrent processes. In this case, hard disks
are used for the operating system to swap out inactive processes, which may
later be swapped back into the main memory.
3.2 Memory partitioning
Allocating a single contiguous section of memory to each process is the
most primitive method of memory management, usually called partitioning. It
has been used in some now-obsolete operating systems. Each single section is
called a partition.
3.2.1 Fixed partitioning
The simplest partitioning method is dividing memory into several fixed-
sized partitions in advance, called fixed partitioning. Each partition may
contain exactly one process. As the following Figure
(a) shows, a 64M memory is divided into 8 equal-size partitions with 8
megabytes each. Any process whose size is less than or equal to the partition
size can be loaded into any partition available. And when no partition is
available and a new process is to be loaded, a process already residing in main
memory may be selected to be swapped out to free a partition. So for this
method is very simple.
However two disadvantages are present with it:
• A program that is too big to be held in a partition needs some special design,
called overlay, which brings heavy burden on programmers. With overlay, a
process consists of several portions with each being mapped to the same
location of the partition, and at any time, only one portion may reside in the
partition. When another portion is referenced, the current portion will be
switched out.
• A program may be much smaller than a partition, thus space left in the
partition will be wasted, which is referred to as internal fragmentation. As an
improvement shown in Figure (b), unequal-size partitions may be configured in
main memory so that small programs will occupy small partitions and big

36
 Operating system 8 Operating system
M 8M

8M 2M

4M

8M 6M

8M
8M

8M 8M

8M
12 M
8M

16 M
8M

a.Equal- size partitions b.Unequal-size partitions

programs are also likely to be able to fit into big partitions. Although this may
solve the above problems with fixed equal-size partitioning to some degree, the
fundamental weakness still exists: The number of partitions are the maximum
of the number of processes that could reside in main memory at the same time.
When most processes are small, the system should be able to accommodate
more of them but fails to do so due to the limitation. More flexibility is needed.
3.2.2 Dynamic partitioning
To overcome difficulties with fixed partitioning, partitioning may be
done dynamically, called dynamic partitioning. With it, the main memory
portion for user applications is initially a single contiguous block. When a new
process is created, the exact amount of memory space is allocated to the
process. Similarly when no enough space is available, a process may be
swapped out temporarily to release space for a new process.
As time goes on, there will appear many small holes in the main
memory, which is referred to as external fragmentation. Thus although much
space is still available, it cannot be allocated to new processes. A method for
overcoming external fragmentation is compaction. From time to time, the
operating system moves the processes so that they occupy contiguous sections

37
and all of the small holes are brought together to make a big block of space.
The disadvantage of compaction is: The procedure is time-consuming and
requires relocation capability.
Address translation
The base register holds the entry point of the program, and may be
added to a relative address to generate an absolute address. The bounds register
indicates the ending location of the program, which is used to compare with
each physical address generated. If the later is within bounds, then the
execution may proceed; otherwise, an interrupt is generated, indicating illegal
access to memory. The relocation can be easily supported with this mechanism
with the new starting address and ending address assigned respectively to the
base register and the bounds register.
Placement algorithm
Different strategies may be taken as to how space is allocated to
processes:
• First fit:
Allocate the first hole that is big enough. Searching may start either at
the beginning of the set of holes or where the previous first-fit search ended.
• Best fit:
Allocate the smallest hole that is big enough. The entire list of holes
must be searched unless it is sorted by size. This strategy produces the smallest
leftover hole.
• Worst fit:
Allocate the largest hole. In contrast, this strategy aims to produce the
largest leftover hole, which may be big enough to hold another process.
Experiments have shown that both first fit and best fit are better than worst fit
in terms of decreasing time and storage utilization.
3.3 Paging
3.3.1 Pages and frames
Both fixed-sized and variable-sized partitions are inefficient due to the
problem of either internal or external fragmentation. The fundamental reason of
the inefficiency is that each program is allocated a monolithic section of
memory. To permit the process image in the main memory to be
noncontiguous, we break the main memory into fixed-sized blocks called
frames and break the process image into blocks of the same size called pages.
When a process is to be executed, its pages are loaded into any available
frames, as illustrated in the following Figure. The frames allocated to a single
process may be contiguous or not.
3.3.2 Page table and address translation
To transform the logical addresses into physical ones, a simple base
address register will no longer suffice. Instead, a page table is needed. As
shown in the following Figure, each entry in a page table associates a page with
a frame. The number of the frame holding page i is available in item i of the

38
page table. Accordingly, a list of free frames is maintained by the operating
system.
To facilitate the address translation, the frame or page size is always a
power of 2 so that a relative address in the logical address space can be easily
split into two parts: the page number and the offset address. For example,
suppose 16-bit addresses are used, and the page size is 1K = 1024 bytes. Thus
10 bits are needed as an offset in a page, leaving 6 bits for the page number. As
Figure 9 (b) shows, the relative address 1502, which in binary form is
0000010111011110, responds to an offset of 478 (0111011110) on page 1
(000001). Using a page size that is a power of 2 thus makes it easier not only
for a compiler/linker to generate logical addresses prepared for this paging
scheme, but also for the hardware to support the translation.
Consider an address of n+m bits, where the leftmost n bits specifies the
page number and the rightmost m bits are the offset address, then as Figure 10
(a) illustrates, the following steps are needed for address translation:
1. Extract the leftmost n bits of the logical address as the page number.
2. Use the page number as an index into the process page table to find the
corresponding frame number, k.
3. The starting physical address of the frame is k × 2m, and the physical
address of the referenced byte is that number plus the offset, which may be
easily constructed by appending the offset to the frame number. Paging makes
sharing easier by simply associating the frames holding the shared code with
the pages in each process involved.
3.3.3 Hardware support
Each computer system has its own methods for supporting paging,
whose major part is how page tables are implemented. The page tables can be
done in several ways:
• A set of registers may be dedicated to an extreme fast but small page
table. For example, in the DEC PDP-11 system, the address consists of 16 bits,
the page size is 8KB. The page table thus consists of only eight entries, which
may feasibly stored in registers. The contents of all these registers are stored in
the PCB when a process loses the processor so that they may be resumed again.
• To allow large page tables, a section of main memory may be used
and a page table base register points to it. Thus when the context is switched
and a new process is dispatched, changing page tables requires changing only
this one register. The problem with this scheme is the time required to access a
location in the process image. For any access, two accesses to the main
memory is needed, first the frame number in the page table and second the
desired destination location. Since the access is so frequent that the delay like
this is intolerable. A solution to this problem is to use a small but fast cache,
called translation look-aside buffer (TLB for short). Each entry in the TLB
consists of two parts: a key for the page number, and a value for the
corresponding frame number. When an address needs to be translated, the page
number may be compared simultaneously with all keys in the TLB. If the

39
number is found, then the corresponding value field is returned so that the
physical address is obtained.
3.4 Segmentation
Paging is in some sense similar to fixed partitioning since each page is
of fixed size, but is different since multiple pages may be used instead of one
single partition in the latter. Interestingly, another memory management
approach, segmentation, is similar to dynamic partitioning. With segmentation,
a program is divided into several segments, each similar to a partition of varied
size. Segmentation avoids internal fragmentations which are present in both
fixed partitioning and paging, but like dynamic partitioning, it suffers from
external fragmentation. However the problem is not that serious because a
process may be broken into a number of smaller pieces and the resulting
external holes will be much smaller.
Different from paging, which is invisible to the programmer and the
compiler, segmentation, is usually visible, which is actually based on the
programmers’ logical view of programs. Typically, the programmers will
assign programs and data to different segments, thus leading to a major
advantage of segmentation that the protection and sharing may be easily
supported. With segmentation, the logical addresses and physical addresses do
not have a simple relationship any more like with partitioning and paging. Each
logical address is explicitly expressed by a two tuple: ¡segment-number,
offset¿, The operating system maintains a segment table for each process and a
list of free blocks of main memory. Each segment table entry would have to
give the starting address in main memory of the corresponding segment, as well
as the length of the segment to assure that invalid addresses are not used.
Paging and segmentation nowadays have been combined to eliminate both
external and internal fragmentation, and facilitate programmer’s control on
programs. An example for this is the architecture of the Intel 80x86.
3.5 Virtual Memory
The conceptual separation of user logical memory from physical
memory. Thus we can have large virtual memory on a small physical memory.
Because main memory (i.e.,transistor memory) is much more expensive, per bit
than disk memory (presently, approximately 10 to 50 times more expensive), it
is usually economical to provide most of the memory requirements of a
computer system as disk memory. Disk memory is also ``permanent'' and not
(very) susceptible to such things as power failure. Data, and executable
programs, are brought into memory, or swapped as they are needed by the CPU
in much the same way as instructions and data are brought into the cache. Most
large systems today implement this ``memory management'' using a hardware
memory controller in combination with the operating system software.
One of the most primitive forms of ``memory management'' is often
implemented on systems with a small amount of main memory. This method
leaves the responsibility of memory management entirely to the programmer; if
a program requires more memory than is available, the program must be broken
up into separate, independent sections and one ``overlaid'' on top of another

40
when that particular section is to be executed. This type of memory
management, which is completely under the control of the programmer, is
sometimes the only type of memory management available for small
microcomputer systems. Modern memory management schemes, usually
implemented in mini - to mainframe computers, employ an automatic, user
transparent scheme, usually called ``virtual memory''.
In a computer system which supports virtual memory management, the
computer appears to the programmer to have its address space limited only by
the addressing range of the computer, not by the amount of memory which is
physically connected to the computer as main memory. In fact, each process
appears to have available the full memory resources of the system. Processes
can occupy the same virtual memory but be mapped into completely different
physical memory locations. Of course, the parts of a program and data which
are actually being executed must lie in main memory and there must be some
way in which the ``virtual address'' is translated into the actual physical address
in which the instructions and data are placed in main memory. The process of
translating, or mapping, a virtual address into a physical address is called
virtual address translation. The following Figure shows the relationship
between a named variable and its physical location in the system.

Figure: The name space to physical address mapping

This mapping can be accomplished in ways similar to those discussed
for mapping main memory into the cache memory. In the case of virtual
address mapping, however, the relative speed of main memory to disk memory
(a factor of approximately 10,000 to 100,000) means that the cost of a ``miss''
in main memory is very high compared to a cache miss, so more elaborate

41
replacement algorithms may be worthwhile.) In fact, in most processors, a
direct mapping scheme is supported by the system hardware, in which a page
map is maintained in physical memory. This means that each physical memory
reference requires both an access to the page table and an operand fetch. In
effect, all memory references are indirect. The following figure shows a typical
virtual-to-physical address mapping.

Figure: A direct mapped virtual to physical address translation

This requirement would be a considerable performance penalty, so most
systems which support virtual addressing have a small associative memory
(called a translation lookaside buffer, or TLB) which contains the last few
virtual addresses and their corresponding physical addresses, so in most cases
the virtual to physical mapping does not require an additional memory access.
The following Figure shows a typical virtual-to-physical address mapping in a
system containing a TLB.

Figure: A virtual to physical address translation mechanism with a TLB

For many current architectures, including the VAX, INTEL 80486, and
MIPS, addresses are 32 bits, so the virtual address space is 232 bytes, or 4 G
bytes. A physical memory of about 16-64 M bytes is typical for these

42
machines, so the virtual address translation must map the 32 bits of the virtual
memory address into a corresponding area of physical memory.
Sections of programs and data not currently being executed normally
are stored in disk, and are brought into main memory as necessary. If a virtual
memory reference occurs to a location not currently in physical memory, the
execution of that instruction is aborted, and can be restored again when the
required information is placed in main memory from the disk by the memory
controller. (Note that, when the instruction is aborted, the processor must be
left in the same state it would have been had the instruction not been executed
at all). While the memory controller is fetching the required information from
disk, the processor can be executing another program, so the actual time
required to find the information on the disk (the disk seek time) is not wasted
by the processor. In this sense, the disk seek time usually imposes little (time)
overhead on the computation, but the time required to actually place the
information in memory may impact the time the user must wait for a result. If
many disk seeks are required in a short time, however, the processor may have
to wait for information from the disk.
3.5.1 Segmented memory management
In a segmented memory management system the blocks to be replaced
in main memory are potentially of unequal length and correspond to program
and data ``segments.'' A program segment might be, for example, a subroutine
or procedure. A data segment might be a data structure or an array. In both
cases, segments correspond to logical blocks of code or data. Segments, then,
are ``atomic,'' in the sense that either the whole segment should be in main
memory, or none of the segment should be there. The segments may be placed
anywhere in main memory, but the instructions or data in one segment should
be contiguous, as shown in the following figure.

Figure: A segmented memory organization

43
 Using segmented memory management, the memory controller needs to
know where in physical memory is the start and the end of each segment. When
segments are replaced, a single segment can only be replaced by a segment of
the same size, or by a smaller segment. After a time this results in a ``memory
fragmentation'', with many small segments residing in memory, having small
gaps between them. Because the probability that two adjacent segments can be
replaced simultaneously is quite low, large segments may not get a chance to
be placed in memory very often. In systems with segmented memory
management, segments are often ``pushed together'' occasionally to limit the
amount of fragmentation and allow large segments to be loaded.
This organization appears to be efficient because an entire block of code
is available to the processor. Also, it is easy for two processes to share the same
code in a segmented memory system; if the same procedure is used by two
processes concurrently, there need only be a single copy of the code segment in
memory. (Each process would maintain its own, distinct data segment for the
code to access, however.)
Segmented memory management is not as popular as paged memory
management, however. In fact, most processors which presently claim to
support segmented memory management actually support a hybrid of paged
and segmented memory management, where the segments consist of multiples
of fixed size blocks.
3.5.2 Paged Memory Management
Paged memory management is really a special case of segmented
memory management. In the case of paged memory management,
 all of the segments are exactly the same size (typically 256 bytes to 16
K bytes)
 Virtual ``pages'' in auxiliary storage (disk) are mapped into fixed page-
sized blocks of main memory with predetermined page boundaries.
 the pages do not necessarily correspond to complete functional blocks
or data elements, as is the case with segmented memory management.
The pages are not necessarily stored in contiguous memory locations,
and therefore every time a memory reference occurs to a page which is not the
page previously referred to, the physical address of the new page in main
memory must be determined. In fact, most paged memory management
systems (and segmented memory management systems as well) maintain a
``page translation table'' using associative memory to allow a fast determination
of the physical address in main memory corresponding to a particular virtual
address. Normally, if the required page is not found in the main memory (i.e, a
``page fault'' occurs) then the CPU is interrupted, the required page is requested
from the disk controller, and execution is started on another process.
The following is an example of a paged memory management
configuration using a fully associative page translation table:
Consider a computer system which has 16 M bytes (221 bytes) of main
memory, and a virtual memory space of 232 bytes. The Figure below shows a

44
sketch of the page translation table required to manage all of main memory if
the page size is 4K (212) bytes. Note that the associative memory is 20 bits wide
(32 bits - 12 bits, the virtual address size -- the page size). Also to manage
16 M bytes of memory with a page size of 4 K bytes, a total of
(16M=221)/(4K=212)=212=4096 associative memory locations are required.

Figure: Paged memory management address translation

Some other attributes are usually included in a page translation table, s
well, by adding extra fields to the table. For example, pages or segments may
be characterized as read only, read-write, etc. As well, it is common to include
information about access privileges, to help ensure that one program does not
inadvertently corrupt data for another program. It is also usual to have a bit )the
``dirty'' bit) which indicates whether or not a page has been written to, so that
the page will be written back onto the disk if a memory write has occurred into
that page. (This is done only when the page is ``swapped'', because disk access
times are too long to permit a ``write-through'' policy like cache memory.)
Also, since associative memory is very expensive, it is not usual to map all of
main memory using associative memory; it is more usual to have a small
amount of associative memory which contains the physical addresses of
recently accessed pages, and maintain a ``virtual address translation table'' in
main memory for the remaining pages in physical memory. A virtual to
physical address translation can normally be done within one memory cycle if
the virtual address is contained in the associative memory; if the address must
be recovered from the ``virtual address translation table'' in main memory, at
least one more memory cycle must be used to retrieve the physical address
from main memory.
There is a kind of trade-off between the page size for a system and the
size of the page translation table (PTT). If a processor has a small page size,

45
then the PTT must be quite large to map all of the virtual memory space. For
example, if a processor has a 32 bit virtual memory address, and a page size of
512 bytes ( 29bytes), then there are 223possible page table entries. If the page
size is increased to 4 Kbytes ( 212bytes), then the PTT requires ``only'' 220, or 1
M page table entries. These large page tables will normally not be very full,
since the number of entries is limited to the amount of physical memory
available. One way these large, sparse PTT's are managed is by mapping the
PTT itself into virtual memory. (Of course, the pages which map the virtual
PTT must not be mapped out of the physical memory!)
Note that both paged and segmented memory management provide the
users of a computer system with all the advantages of a large virtual address
space. The principal advantage of the paged memory management system over
the segmented memory management system is that the memory controller
required to implement a paged memory management system is considerably
simpler. Also, the paged memory management does not suffer from
fragmentation in the same way as segmented memory management. Another
kind of fragmentation does occur, however. A whole page is swapped in or out
of memory, even if it is not full of data or instructions. Here the fragmentation
is within a page, and it does not persist in the main memory when new pages
are swapped in.
One problem found in virtual memory systems, particularly paged
memory systems, is that when there are a large number of processes executing
``simultaneously'' as in a multi-user system, the main memory may contain
only a few pages for each process, and all processes may have only enough
code and data in main memory to execute for a very short time before a page
fault occurs. This situation, often called ``thrashing,'' severely degrades the
throughput of the processor because it actually must spend time waiting for
information to be read from or written to the disk.
3.6 HARDWARE AND CONTROL STRUCTURES
Comparing simple paging and simple segmentation, on the one hand,
with fixed and dynamic partitioning, on the other, we see the foundation for a
fundamental break-through in memory management. Two characteristics of
paging and segmentation are the keys to this breakthrough:
1. All memory references within a process are logical addresses that are
dynamically translated into physical addresses at run time. This means
that a process may be swapped in and out of main memory such that it
occupies different regions of main memory at different times during
the course of execution.
2. A process may be broken up into a number of pieces need not be
contiguously located in main memory during execution. The
combination of dynamic run-time address translation and the use of a
page or segment table permits this.

46
Now we come to the breakthrough. If the preceding two characteristics are
present, then it is not necessary that all of the segments of a process be in main
memory during execution. If the piece that holds the next instruction to br
fetched and the piece that holds the next data location to be accessed are in
main memory, then at least for a time execution may proceed.
Let us consider how this may be accomplished. For now, we can talk in
general terms, and we will use the term piece to refer to either page or segment,
depending on whether paging or segmentation is employed. Suppose that it is
time to bring a new process into memory. The operating system begins by
bringing in only one or a few pieces, to include the initial program piece and
the initial data piece to which those instructions refer. The portion of a process
that is actually in main memory at any time is defined to be the resident set of
the process. As the process executes, things proceed smoothly as long as all
memory references are to locations that are in the resident set. Using the
segment or page table, the processor always is able to determine whether this is
so, if the processor encounters a logical address that is not in main memory, it
generates an interrupt indicating a memory access fault. The operating system
puts the interrupted process in a blocking state and takes control. For the
execution of this process to proceed later, the operating system will need to
bring into main memory the piece of the process that contains the logical
address that caused the access fault. For this purpose, the operating system
issues a disk I/O read request. After the I/O request has been issued, the
operating system can dispatch another process to run while the disk I/O is
performed. Once the desired piece has been brought into main memory, an I/O
interrupt is issued, giving control back to the operating system, which places
the affected process back into a Ready state.
It may immediately occur to you to question the efficiency of this
maneuver, in which a process may be executing and have to be interrupted for
no other reason than that you have failed to load in all of the needed pieces of
the process. For now, let us defer consideration of this question with the
assurance that efficiency is possible. Instead, let us ponder the implications of
our new strategy. There are two implications, the second more starting than the
first, and both lead to improved system utilization:
1. More process may be maintained in main memory. Because we are
only going to load some of the pieces of any particular process, there is
room for more processes. This lead to more efficient utilization of the
processor because it is more likely that at least one of the more
numerous processes will be in a Ready state at any particular time.
2. A process may be larger than all of main memory. One of the most
fundamental restrictions in programming is lifted. Without the scheme
we have been discussing, a programmer must be acutely aware of how
much memory is available. If the program being written is too large,
the programmer must devise ways to structure the program into pieces
that can be loaded separately in some sort of overlay strategy. With
virtual memory based on paging or segmentation, that job is left to the

47
 operating system and the hardware. As far as the programmer is
concerned, he or she is dealing with a huge memory, the size
associated with disk storage. The operating system automatically loads
pieces of a process into main memory as required.
Because a process executes only in main memory, that memory is
referred to as real memory. But a programmer or user perceives a potentially
much larger memory that which is allocated on disk. This latter is referred to as
a virtual memory. Virtual memory allows for very effective multiprogramming
and relieves the user of the unnecessarily tight constraints of main memory.
3.7 HARDWARE AND CONTROL STRUCTURES
Comparing simple paging and simple segmentation, on the one hand,
with fixed and dynamic partitioning, on the other, we see the foundation for a
fundamental break-through in memory management. Two characteristics of
paging and segmentation are the keys to this breakthrough:
1. All memory references within a process are logical addresses that are
dynamically translated into physical addresses at run time. This means
that a process may be swapped in and out of main memory such that it
occupies different regions of main memory at different times during the
course of execution.
2. A process may be broken up into a number of pieces need not be
contiguously located in main memory during execution. The
combination of dynamic run-time address translation and the use of a
page or segment table permit this.
Now we come to the breakthrough. If the preceding two characteristics
are present, then it is not necessary that all of the segments of a process be in
main memory during execution. If the piece that holds the next instruction to be
fetched and the piece that holds the next data location to be accessed are in
main memory, then at least for a time execution may proceed.
Let us consider how this may be accomplished. For now, we can talk in
general terms, and we will use the term piece to refer to either page or segment,
depending on whether paging or segmentation is employed. Suppose that it is
time to bring a new process into memory. The operating system begins by
bringing in only one or a few pieces, to include the initial program piece and
the initial data piece to which those instructions refer. The portion of a process
that is actually in main memory at any time is defined to be the resident set of
the process. As the process executes, things proceed smoothly as long as all
memory references are to locations that are in the resident set. Using the
segment or page table, the processor always is able to determine whether this is
so, if the processor encounters a logical address that is not in main memory; it
generates an interrupt indicating a memory access fault. The operating system
puts the interrupted process in a blocking state and takes control. For the
execution of this process to proceed later, the operating system will need to
bring into main memory the piece of the process that contains the logical
address that caused the access fault. For this purpose, the operating system

48
issues a disk I/O read request. After the I/O request has been issued, the
operating system can dispatch another process to run while the disk I/O is
performed. Once the desired piece has been brought into main memory, an I/O
interrupt is issued, giving control back to the operating system, which places
the affected process back into a Ready state.
It may immediately occur to you to question the efficiency of this
maneuver, in which a process may be executing and have to be interrupted for
no other reason than that you have failed to load in all of the needed pieces of
the process. For now, let us defer consideration of this question with the
assurance that efficiency is possible. Instead, let us ponder the implications of
our new strategy. There are two implications, the second more starting than the
first, and both lead to improved system utilization:
1. More process may be maintained in main memory. Because we are
only going to load some of the pieces of any particular process, there is
room for more processes. This lead to more efficient utilization of the
processor because it is more likely that at least one of the more
numerous processes will be in a Ready state at any particular time.
2. A process may be larger than all of main memory. One of the most
fundamental restrictions in programming is lifted. Without the scheme
we have been discussing, a programmer must be acutely aware of how
much memory is available. If the program being written is too large,
the programmer must devise ways to structure the program into pieces
that can be loaded separately in some sort of overlay strategy. With
virtual memory based on paging or segmentation, that job is left to the
operating system and the hardware. As far as the programmer is
concerned, he or she is dealing with a huge memory, the size
associated with disk storage. The operating system automatically loads
pieces of a process into main memory as required.
Because a process executes only in main memory, that memory is
referred to as real memory. But a programmer or user perceives a potentially
much larger memory that which is allocated on disk. This latter is referred to as
a virtual memory. Virtual memory allows for very effective multiprogramming
and relieves the user of the unnecessarily tight constraints of main memory.
3.7.1 COMPUTERS AND SOFTWARE
Computer systems consist of software and hardware that are combined
to provide a tool to solve specific problems. Software is differentiated
according to its purpose. Application software is designed to solve a specific
problem. For example, inventory control application software uses the
computer to track and report a company’s inventory. System software provides
a general programming environment in which programmers can create specific
applications to suit their needs. This environment provides new functions that
are not available at the hardware level and performs tasks related to executing
the application program. The OS is a subset of the system software.

49
 The original motivation for system software in general and operating
systems in particular was to provide functions that a programmer could use to
implement application software. Over time, another important purpose of
operating systems evolved enabling application software to share the hardware
in an orderly fashion. This sharing increase overall system performance by
allowing different programs to use different parts of the computer
simultaneously, thereby decreasing the time needed to execute a collection of
programs and increasing the system’s performance. To ensure that this sharing
is done most safely and efficiently, the OS is the software that is implemented
“closest to the hardware”. Other system software and all application software
use the OS as an interface to the hardware and as a means to support sharing
among executing programs.
Before focusing on system software and operating systems, it is
important to stress the overall importance of the application software.
Ultimately, the cost of any computer is justified by the value of its application
software. That is a person or a company buys a computer ton solve problem in
one or more application domains; anything other than the application software
is apart of the overhead cost of solving the problem. In particular system
software is usually no more important to the computer purchaser than, say, the
power supply in the hardware.System software and hardware exist to support
the creation and effective use of application software.
3.7.2 GENERAL SYSTEM SOFTWARE
From the application programmer’s perspective, system software is
meant to simplify the programming environment and to enable efficient use of
the hardware. System software covers a broad spectrum of functionality. An
important class of system software is the runtime system for a programming
language. In the UNIX system software, important parts of this runtime
functionality are implemented in C libraries; for example:
 The standard input/output (I/O) library provides procedures to perform
buffered input/output on a stream of data.
 The math library provides functions to compute trigonometric and
other mathematical functions.
 Graphics libraries provide functions to render images on a bitmapped
display.
A database management system is a full system That can be used to
store information on the computer’s permanent storage devices such as
magnetic tapes and disks. The database system provides abstract data types
(called schema) and creates new application-specific software optimized for
efficient queries/updates on the data according to the schema definition.
An OS interacts directly with the hardware to provide an interface to
other system software and with application software whenever it wants to use
system resources. It is largely domain-independent. This means that the same
OS can be used to support a broad range of application domains, such as
inventory management software and software for computing fluid flow over an

50
airplane wing. The application program uses the resource abstraction provided
by the OS to determine its detailed interaction with the hardware components.
The OS allows different applications to share the hardware resources through
its resource management policies. Resource abstraction and sharing are two key
aspects of the operating system.
3.7.3 COMPUTERS WITHOUT SYSTEM SOFTWARE
If application software can be constructed without a need for resource
abstraction or sharing, there is probably no need for system software. This was
the case with early personal computers. Devices were deemed to be simple as
to not require resource abstraction, and there was no requirement to support
concurrency through processor multiplexing. The application program was
responsible for all I/O operations on, for example, the keyboard, display, and
disk. The complexities of device I/O and the popularity of the mouse pointing
devices soon signaled the end of this era because the software to control these
devices became far too complex for most application programmers to manage.
Personal computer manufacturers began to include resource abstraction
mechanisms built into ROM. The BIOS routines in IBM personal computers
are one example of this.

Application
Software

Application
Programming
Interface

Other System Software

Operating System
Interface

Operating System

Software-Hardware
Interface

Hardware

51
 Since then, personal computers have become so powerful that there is a
growing need to support concurrent execution through processor multiplexing.
As a consequence, contemporary personal computer system software now
includes a resource-sharing mechanism.

SELF-ASSESSMENT QUESTIONS: I

ANSWER THE FOLLOWING QUESTIONS

1. What is Main Memory?

---------------------------------------------

2. What is Worst fit?

---------------------------------------------

3. If application software can be constructed without

a need for resource abstraction or sharing, there
is probably no need for ________.

UNIT QUESTIONS
1. What is a main memory?.
2. Explain about paging.
3. Describe elaborately about Virtual memory.
4. Explain in detail about Hardware and control structures.
RECOMMENDATIONS FOR FURTHER READING
1. Operating Systems – A Modern Perspective, Gary Nutt, Pearson
Education Asia, Second Edition.
2. Operating Systems – Internals and Design Principles, William Stallings,
Pearson Education, Fifth Edition.
3. Operating Systems – Internals and Design Principles, William Stallings,
Eastern Economy Edition, Fifth Edition.
ANSWERS OF SELF-ASSESSMENT QUESTIONS
1. Main memory is a very important component in a computer system
because both the operating system and various user applications have
to be loaded into main memory first before being able to be executed.
2. Allocate the largest hole. In contrast, this strategy aims to produce the
largest leftover hole, which may be big enough to hold another process.
3. System software.

52
 NOTES
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..

53
 UNIT - IV
UNIPROCESSOR SCHEDULING

UNIT STRUCTURES

4.1 UNIPROCESSOR SCHEDULING

4.2 TYPES OF SCHEDULING
4.3 SCHEDULING ALGORITHMS
4.3.1 FIRST-COME, FIRST-SERVED SCHEDULING
4.3.2 SHORTEST-JOB-FIRST SCHEDULING
4.3.3 ROUND-ROBIN SCHEDULING
4.3.4 MULTILEVEL QUEUE SCHEDULING
4.3.5 MULTILEVEL FEEDBACK-QUEUE SCHEDULING
4.4 MULTIPLE-PROCESSOR SCHEDULING
4.5 I/O MANAGEMENT AND DISK SCHEDULING
4.5.1 I/O DEVICES
4.5.2 ORGANIZATION OF THE I/O FUNCTION
4.5.3 The Evolution of the I/O Function
4.5.4 Direct Memory Access
4.5.5 I/O BUFFERING
4.6 DISK SCHEDULING
4.6.1 FCFS SCHEDULING
4.6.2 SSTF SCHEDULING
4.6.3 SCAN SCHEDULING
4.6.4 C-SCAN SCHEDULING
4.6.5 LOOK SCHEDULING

SELF-ASSESMENT QUESTIONS: I

UNIT QUESTIONS
RECOMMENDATIONS FOR FURTHER READING
ANSWER OF SELF-ASSEEEMENT QUESTIONS

54
 UNIT IV : UNIPROCESSOR SCHEDULING

4.1 UNIPROCESSOR SCHEDULING

The aim of processor scheduling is to assign processes to be executed
by the processor over time, in a way that meets system objectives, such as
response time, throughput, and processor efficiency. In many systems, this
scheduling activity is broken down into three separate functions:long-,
medium-,and short-term scheduling. The names suggest the relative time scales
with which these functions are performed.
4.2 Types of Scheduling
Long-Term Scheduling
The long-term scheduler determines which program is admitted to the
system for processing. Thus, it controls the degree of multiprogramming. Once
admitted, a job or user program becomes a process and is added to the queue
for the short-term scheduler. In some systems, a newly created process begins
in a swapped-out condition, in which case it is added to a queue for the
medium-term scheduler.
In a batch system, or for the batch portion of a general-purpose
operating system, newly submitted jobs are routed to disk and held in a batch
queue. The long-term scheduler creates processes from the queue when it can.
There are two decisions involved here. First, the scheduler must decide which
job or jobs to accept and turn into processes. Let us briefly consider these two
decisions.
Medium-Term Scheduling
Medium-term scheduling is part of the swapping function. Typically,
the swapping-in decision is based on the need to manage the degree of
multiprogramming. On a system that does not use virtual memory, memory
management is also an issue. Thus, the swapping-in decision will consider the
memory requirements of the swapped-out processes.
Short-Term Scheduling
In terms of frequency of execution, the long-term scheduler executes
relatively infrequently and makes the coarse-grained decision of whether or not
to take on a new process and which one to take. The medium-term scheduler is
executed some what more frequently to make a swapping decision. The short-
term scheduler, also known as the dispatcher, executes most frequently and
makes the fine-grained decision of which process to execute next. The short-
term scheduler is invoked whenever an event occurs that may lead to the
blocking of the current process or that may provide an opportunity to preempt a
currently running process in favors of another. Examples of such events include
 Clock interrupts
 I/O interrupts
 Operating system calls

55
  Signals(e.g.,semaphores)
4.3 Scheduling Algorithms
Short-Term Scheduling Criteria
The main objective of short-term scheduling is to allocate processor
time in such a way as to optimize one or more aspects of system behavior.
Generally, a set of criteria is established against which various scheduling
policies may be evaluated.
The commonly used criteria can be categorized along two dimensions.
First, we can make a distinction between user-oriented and system-oriented
criteria. User-oriented criteria relate to the behavior of the system as perceived
by the individual user or process. An example is response time in an interactive
system. Response time is the elapsed time between the submissions of a request
until the response begins to appear as output. This quantity is visible to the user
and is naturally of interest to the users. In the case of response time, a threshold
may be defined, say 2 seconds. Then a goal of the scheduling mechanism
should be to maximize the number of users who experience an average
response time of 2 seconds or less.
Other criteria are system oriented. That is, the focus is on effective
utilization of the processor. An example is throughput, which processes are
completed. This is certainly a worthwhile measure of system performance and
one that we would like to maximize. However, it focuses on system
performance rather than service provide to the user. Thus, throughput is of
concern to a system administrator but not to the user population.
The selection function determines which process, among ready
processes, is selected next for execution. The function may be based on
priority, resource requirements, or the execution characteristics of the process.
In the latter case, three quantities are significant:
W= time spent in system so far, waiting and executing
e= time spent in execution so far
s= total service time required by the process, including
e; generally, this quantity must be estimated or supplied by the user. For
example, the selection function max[w] indicates a first-come-first-served
(FCFS) discipline.
The decision mode specifies the instants in time at which the selection
function is exercised. There are two general categories:
 Non preemptive: In this case, once a process is in the running state,
it continues to execute until(a) it terminates or(b)it blocks itself to
wait for I/O or to request some operating system service.
 Preemptive: The currently running process may be interrupted and
moved to the ready state by the operating system. The decision to
preempt may be performed when a new process arrives; when an
interrupt occurs that places a blocked in the ready state; or
periodically, based on a clock interrupt.

56
 CPU scheduling deals with the problem of deciding which of the
processes in the ready queue is to be allocated the CPU.
4.3.1 First-Come, First-Served Scheduling
By far the simplest CPU-scheduling algorithm is the first-come, first-
served (FCFS) scheduling algorithm. With this scheme, the process that
requests the CPU first is allocated the CPU first. The implementation of the
FCFS policy is easily managed with a FIFO queue. When a process enters the
ready queue, its PCB is linked onto the tail of the queue. When the CPU is free,
it is allocated to the process at the head of the queue. The running process is
then removed from the queue. The code for FCFS scheduling is simple to write
and understand.
4.3.2 Shortest-Job-First Scheduling
A different approach to CPU scheduling is the shortest-job-first (SJF)
scheduling algorithm. This algorithm associates with each process the length of
the process’s next CPU burst. If the next CPU bursts of two processes are the
same, FCFS scheduling is used to break the tie. Note that a more appropriate
term for this scheduling method would be the shortest-next-CPU-burst
algorithm, because scheduling depends on the length of the next CPU burst of a
process, rather than its total length.
Priority Scheduling
The SJF algorithm is a special case of the general priority scheduling
algorithm. A priority is associated with each process, and the CPU is allocated
to the process with the highest priority. Equal-priority processes are scheduling
in FCFS order. An SJF algorithm is simply a priority algorithm where the
priority (p) is the inverse of the next CPU burst. The larger the CPU burst, the
lower the priority, and vice versa.
Priority scheduling can be either preemptive or no preemptive. When a
process arrives at the ready queue, its priority is compared with the priority of
the currently running process. A preemptive priority scheduling algorithm will
preempt the CPU if the priority of the newly arrived process is higher than the
priority of the currently running process. A nonpreemptive priority scheduling
algorithm will simply put the new process at the head of the ready queue.
A major problem with priority scheduling algorithm is indefinite
blocking, or starvation. A process that is ready to run but waiting for the CPU
can be considered blocked. A priority scheduling algorithm can leave some
low-priority processes waiting indefinitely.
4.3.3 ROUND-ROBIN SCHEDULING
The round-robin (RR) scheduling algorithm is designed especially for
time-sharing systems. It is similar to FCFS scheduling, but preemption is added
to switch between processes. A small unit of time, called a time quantum or
time slice, is defined. A time quantum is generally from 10 to 100 milliseconds.
The ready queue is treated as a circular queue. The CPU scheduler goes around
the ready queue, allocating the CPU to each process for a time interval of up to
1 time quantum.

57
4.3.4 MULTILEVEL QUEUE SCHEDULING
A multilevel queue scheduling algorithm partitions the queue into
several separate queues. The processes are permanently assigned to one queue,
generally based on some property of the process, such as memory size, process
priority, or process type. Each queue has its own scheduling algorithm. For
example, separate queues might be used for foreground and background
processes. The foreground queue might be scheduled by an RR algorithm,
while the background queue is scheduled by an FCES algorithm.
4.3.5 MULTILEVEL FEEDBACK-QUEUE SCHEDULING
The multilevel feedback-queue scheduling algorithm, in contrast, allows
a process to move between queues. The idea is to separate processes according
to the characteristics of their CPU bursts. If a process uses too much CPU time,
it will be moved to a lower-priority queue. This scheme leaves I/O-bound and
interactive processes in the higher-priority queues. In addition, a process that
waits too long in a lower-priority queue may be moved to a higher-priorty
queue. This form of aging prevents starvation.
4.4 MULTIPLE-PROCESSOR SCHEDULING
If multiple CPUs are available, load sharing become possible; however,
the scheduling problem becomes correspondingly more complex. Many
possibilities have been tried; and as we saw with single processor CPU
scheduling, there is no one best solution.
APPROACHES TO MULTIPLE-PROCESSOR SCHEDULING
One approach to CPU scheduling in a multiprocessor system has all
scheduling decisions, I/O processing, and other system activities handled by a
single processor-the master sever. The other processors execute only user code.
This asymmetric multiprocessing is simple because only one processor
accesses the system data structures, reducing the need for data sharing.
A second approach uses symmetric multiprocessing (SMP), where each
processor is self-scheduling. All process may be in a common ready queue, or
each processor may have its own private queue of ready processes.
PROCESSOR AFFINITY
Consider what happens to cache memory when a process has been
running on a specific processor: the data most recently accessed by the
processor; and as a result, successive memory accesses by the process are often
satisfied in cache memory. Now consider what happens if the process migrates
to another processor.
The contents of cache memory must be invalidated for the processor
being migrated from, and the cache for the processor being migrated to must be
re-populated. Because of the high cost of invalidating and re-populating caches,
most SMP system try to avoid migration of processes from one processor to
another and instead attempt to keep a process running on the same processor.
This is known as processor affinity, meaning that a process has an affinity for
the processor on which it is currently running.

58
LOAD BALANCING
Load balancing attempts to keep the workload evenly distributed across
all processor in an SWP system. It is important to note that load balancing is
typically only necessary on systems where each processor has its own private
queue of eligible process to execute.
There are two general approaches to lead balancing: push migration and
pull migration. With push migration, a specific task periodically checks the
load on each processor and-if it finds an imbalance-evenly distributes the load
by moving processes from overloaded to idle or less or less-busy processors.
Pull migration occurs when an idle processor pulls a waiting task from a busy
processors. Pull migration occurs when an idle processor pulls a waiting task
from a busy processor. Push and pull migration need not be mutually exclusive
and are in fact often implemented in parallel on load-balancing systems.
SYMMETRIC MULTITHREADING
SMP system allows several threads to run concurrently by providing
multiple physical processors. An alternative strategy is to provide multiple
logical-rather than physical-processors. Such a strategy is known as symmetric
Multithreading (or SMT); it has also been termed hyper training technology on
Intel processors.

Logical Logical Logical Logical

CPU CPU CPU CPU

Physical Physical
CPU CPU

Figure: A typical SMT architecture

The idea behind SMT is to create multiple logical processors on the
same physical processor, presenting a View of several logical processors to the
operating system, even on a system with only a single physical processor. Each
logical processor has its own architecture state, which includes general-purpose
and machine-state registers.
4.5 I/O MANAGEMENT AND DISK SCHEDULING
4.5.1 I/O Devices
External devices that engage in I/O with computer systems can be roughly
grouped into three categories:

59
  Human readable: Suitable for communicating with the computer user.
Examples include printers and video display terminals, the later
consisting of display, keyboard, and perhaps other devices such as a
mouse.
 Machine readable: Suitable for communicating with electronic
equipment. Examples are disk and tape drives, sensors, controllers, and
actuators.
 Communication: Suitable for communicating with remote devices.
Examples are digital line drivers and modems.
There are great differences across classes and even substantial
differences within each class. The following are among the key differences:
 Data rate: There may be differences of several orders of magnitude
between the data transfer rates.
 Application: the use to which a device is put has an influence on the
software and policies in the operating system and supporting utilities.
For example, a disk used for files requires the support of file
management software. A disk used as a backing store for pages in a
virtual memory scheme depends on the use of virtual memory hardware
and software.
 Complexity of control: A printer requires a relatively simple control
interface. A disk is much more complex. The effect of these differences
on the operating system is filtered to some extent by the complexity of
the I/O module that controls the devices.
 Unit of transfer: Data may be transferred as a stream of bytes or
characters or in larger blocks (e.g., disk I/O).
 Data representation: Different data encoding schemes are used by
different devices, including differences in character code and parity
conventions.
 Error conditions: The nature of errors, the way in which they are
reported, their consequences, and the available range of responses differ
widely from one device to another.
4.5.2 ORGANIZATION OF THE I/O FUNCTION
 Programmed I/O: The processor issues an I/O command, on behalf of
a process, to an I/O module; that process then busy waits for the
operation to be completed before proceeding.
 Interrupt-driven I/O: The processor issues an I/O command on behalf
of a process, continues to execute subsequent instructions, and is
interrupted by the I/O module when the latter completed its work. The
subsequent instructions may be in the same process, if it is not
necessary for that process to wait for the completion of the I/O.
otherwise, the process is suspended pending the interrupt and other
work is performed.

60
  Direct memory access (DMA): A DMA module controls the exchange
of data between main memory and an I/O module. The processor sends
a request for the transfer of a block of data to the DMA module and is
interrupted only after the entire block has been transferred.
4.5.3 The Evolution of the I/O Function
As computer systems have evolved, there has been a pattern of
increasing complexity and sophistication of individual components. Nowhere is
this more evident than in the I/O function. The evolutionary steps can be
summarized as follows:
1. The processor directly controls a peripheral device. This is seen in
simple microprocessor-controlled devices.
2. A controller or I/O module is added. The processor uses programmed
I/O without interrupts. With this step, the processor becomes somewhat
divorced from the specific details of external device interfaces.
3. The same configuration as step2 is used, but now interrupts are
employed. The processor need not spend time waiting for an I/O
operation to be performed, thus increasing efficiency.
4. The I/O module is given direct control of memory via DMA. It can now
move a block of data to or from memory without involving the
processor, except at the beginning and end of the transfer.
5. The I/O module is enhanced to become a separate processor, with a
specialized instruction set tailored for I/O. the central processing unit
(CPU) directs the I/O processor to execute an I/O program in main
memory. The I/O processor fetches and executes these instructions
without processor intervention. This allows the processor to specify a
sequence of I/O activities and to be interrupted only when the entire
sequence has been performed.
6. The I/O module has a local memory of its own and is, in fact, a
computer in its own right. With this architecture, a large set of I/O
devices can be controlled, with minimal processor involvement. A
common use for such architecture has been to control communications
with interactive terminals. The I/O processor takes involved in
controlling the terminals.
4.5.4 Direct Memory Access
The DMA unit is capable of mimicking the processor and, indeed, of
taking over control of the system bus just like a processor. It needs to do this to
transfer data to and from memory over the system bus.
The DMA technique works as follows. When the processor wishes to
read or write a block of data, it issues a command to the DMA module by
sending to the DMA module the following information:
 Whether a read or write is requested, using the read or write control line
between the processor and the DMA module.
 The address of the I/O device involved, communicated on the data lines.

61
  The starting location in memory to read from or write to, communicated
on the data lines and stored by the DMA module in its address register.
 The number of words to be read or written, again communicated via the
data lines and stored in the data count register.
4.5.5 I/O BUFFERING
Suppose that a user process wishes to read blocks of data from a tape
one at a time, with each block having a length of 512 bytes. The data are to be
read into a data area within the address space of the user process at virtual
location 1000 to 1511 The simplest way would be to execute an I/O command
to the tape unit and then wait for the data to become available. The waiting
could either be busy waiting or, more practically, process suspension on an
interrupt.
There are two problems with this approach. First, the program is hung
up waiting for the relatively slow I/O to complete. The second problem is that
this approach to I/O interfaces with swapping decisions by the operating
system. Virtual locations 1000 to 1511 must be remain in main memory during
the course of the block transfer. Otherwise some of the data may be lost. If
paging is being used, at least the page containing the target locations must be
locked into main memory. Thus, although portions of the process deadlock. If
the process issues an I/O command, is suspended awaiting the result, and then
is swapped out prior to the beginning of the operation, the process is blocked
waiting on the I/O event, and the I/O operation is blocked waiting for the
process to be swapped in. to avoid this deadlock, the user memory involved in
the I/O operation must be locked in main memory immediately before the I/O
request is issued, even thought the I/O operation is queued and may not be
executed for some time. The same consideration applied to an output operation.
If a block is being transferred from a user process area directly to an I/O
module, then the process is blocked during the transfer and the process may not
be swapped out. To avoid these overheads and inefficiencies, it is some times
convenient to perform input transfers in advance of the request being made and
to perform output transfer some time after the request is made. This technique
is known as buffering. In this section, we look at some of the buffering scheme
that are supported by operating systems to improve the performance of the
system.
In discussing the various approaches to buffering, it is some times
important to make a distinction between two types of I/O devices: block
oriented and stream oriented. Block-oriented device stores information in
blocks that are usually of fixed size and transfers are made one block at a time.
Generally, it is possible to reference data by its block number. Disks and tapes
are examples of block-oriented devices. A stream-oriented device transfers data
in and out as a stream of bytes, with no block structure. Terminals, printers,
communications ports, mouse and other pointing devices, and most other
devices that are not secondary storage are stream oriented.

62
Single Buffer
The simplest type of support that the operating system can provide is
single buffering. When a user process issues an I/O request, the operating
system assigns a buffer in the system portion of main memory to the operation.
For block-oriented devices, the single buffering scheme can be
described as follows: Input transfers are made to the system buffer. When the
transfer is complete, the process moves the block into user space and
immediately requests another block. This is called reading ahead, or anticipated
input; it is done in the expectation that the block will eventually be needed. For
many types of computation, this is a reasonable assumption most of the time
because data are usually accessed sequentially. Only at the end of a sequence of
processing will a block be read in unnecessarily.
This approach will generally provide a speedup compared to the lack of
system buffering. The user process can be processing one block of data while
the next block is being read in. The operating system is able to swap the
process out because the input operation is taking place in system memory
rather than user process memory. This technique does, however, complicate the
logic in the operating system. The operating system must keep track of the
assignment of system buffers to user processes. The swapping logic is also
affected: If the I/O operation involves the same disk that is used for swapping,
it hardly makes sense to queue disk writes to the same device for swapping the
process out. This attempt to swap the process and release main memory will
itself not begin until after the I/O operation finishes, at which time swapping
the process to disk may no longer be appropriate.
Double Buffer
A process now transfers data to one buffer while the operating system
empties the other. This technique is known as double buffering or buffer
swapping. For block-oriented transfer, we can roughly estimate the execution
time as max[C, T]. It is therefore possible to keep the block-oriented device
going at full speed if C<=T. on the other hand, if C>T, double buffering
ensures that the process will not have to wait on I/O.
For stream-oriented input, we again are faced with the two alternative
modes of operation. For line-at-a-time I/O, the user process need not be
suspended for input or output, unless the process runs ahead of the double
buffers. For byte-at-a-time operation, the double buffer offers no particular
advantage over a single buffer of twice the length. In both cases, the
producer/consumer model is followed.
Circular buffer
A double- buffer scheme should smooth out the flow of data between an
I/O device and a process. If the performance of a particular process is the focus
of our concern, then we would like for the I/O operation to be able to keep up
with the process. Double buffering may be inadequate if the process performs
rapid bursts of I/O. in this case, the problem can often be alleviated by using
more than two buffers.

63
 When more than two buffers are used, the collection of buffers is itself
referred to as a circular buffer, with each individual buffer being one unit in the
circular buffer.
The Utility of Buffering
Buffering is a technique that smooths out peaks in I/O demand.
However, no amount of buffering will allow an I/O device to keep pace with a
process indefinitely when the average demand of the process is greater than the
I/O device can service. Even with multiple buffers, all of the buffers will
eventually fill up and the process will have to wait after processing each chunk
of data. However, in a multiprogramming environment, when there is a variety
of I/O activity and a variety of process activity to service, buffering is one tool
that can increase the efficiency of the operating system and the performance of
individual processes.
4.6 DISK SCHEDULING
One of the responsibilities of the operating system is to use the
hardware efficiently. For the disk drives, meeting this responsibility entails
having fast access time and large disk bandwidth. The access time has two
major components. The seek time is the time for the disk arm to move the
heads to the cylinder containing the desired sector. The rotational latency is the
additional time for the disk to rotate the desired sector to the disk head. The
disk bandwidth is the total number of bytes transferred, divided by the total
time between the first request for service and the completion of the last
transfer. We can improve both the access time and the bandwidth by scheduling
the servicing of disk I/O request in a good order.
Whenever a process needs I/O to of from the disk, it issues a system call
to the operating system. The request specifies several pieces of information:
 Whether this operation is input or output
 What the disk address for the transfer is
 What the memory address for the transfer is
 What the number of sectors to be transferred is
4.6.1 FCFS SCHEDULING
The simplest form of disk scheduling is, of course, the first-come, first-
served (FCFS) algorithm. This algorithm is intrinsically fair, but it generally
does not provide the fastest service. Consider, for example, a disk queue with
request for I/O to blocks on cylinders 98, 183, 37, 122, 14, 124, 65, 67, In that
order, if the disk head is initially at cylinder 53, it will first move from 53 to 98,
then to 183, 37, 122, 14, 124, 65, and finally to 67, for a total head movement
of 640 cylinders.
4.6.2 SSTF SCHEDULING
It seems reasonable to service all the requests close to the current head
position before moving the head far away to service other requests. This
assumption is the basis for the shortest-seek-time-first (SSTF) algorithm. The
SSTF algorithm selects the request with minimum seek time from the current

64
head position. Since seek time increases with the number of cylinders traversed
by the head, SSTF chooses the pending request closest to the current head
position.
4.6.3 SCAN SCHEDULING
In the SCAN algorithm, the disk arm starts at one end of the disk and
moves toward the other end, servicing requests as it reaches each cylinder, until
it gets to the other end of the disk. At the other end, the direction of head
movement is reversed, and servicing continues. The head continuously scans
back and forth across the disk. The SCAN algorithm is sometimes called the
elevator algorithm, since the disk arm behaves just like an elevator in a
building, first servicing all the requests going up and then reversing to service
requests the other way.
4.6.4 C-SCAN SCHEDULING
Circular SCAN(C-SCAN) scheduling is a variant of SCAN designed to
provide a more uniform wait time. Like SCAN, C-SCAN moves the head from
one end of the disk to the other, servicing requests along the way. When the
head reaches the other end, however, it immediately returns to the beginning of
the disk, without servicing any requests on the return trip. The C-SCAN
scheduling algorithm essentially treats the cylinders as a circular list that wraps
around from the final cylinder to the first one.
4.6.5 LOOK SCHEDULING
As we described them, both SCAN and C-SCAN move the disk arm
across the full width of the disk. In practice, neither algorithm is often
implemented this way. More commonly, the arm goes only as far as the final
request in each direction. Then, it reverses direction immediately, without
going all the way to the end of the disk. Versions of SCAN and C-SCAN that
follow this pattern are called LOOK and C-LOOK scheduling, because they
look for a request before continuing to move in a given direction.

65
 NOTES
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..

66
 UNIT V : FILE MANAGEMENT

UNIT STRUCTURE

5.1 FILES AND FILE SYSTEMS

5.2 FILE STRUCTURE
5.3 FILE ORGANIZATION AND ACCESS
5.4 FILE DIRECTORIES
5.5 FILE SHARING
5.6 RECORD BLOCKING
5.7 SECONDARY STORAGE MANAGEMENT
5.7.1 File Allocation
5.7.2 Pre allocation versus Dynamic Allocation
5.7.3 FREE SPACE MANAGEMENT

SELF-ASSESMENT QUESTIONS: I

UNIT QUESTIONS
RECOMMENDATIONS FOR READINGS
ANSWER OF SELF-ASSESMENT QUESTIONS

67
 UNIT V : FILE MANAGEMENT

5.1 FILES AND FILE SYSTEMS

From the user’s point of the most important parts of an operating
system. The user to file system provides the resource abstractions typically
associated with secondary storage. The file system permits users to create data
collections, called files, with desirable properties, such as the following:
 LONG-TERM EXISTENCE
Files are stored on disk or other secondary and do not disappear when a
user logs off.
 SHARABLE BETWEEN PROCESS
Files have names and can have associated access permissions that
permit controlled sharing.
 STRUCTURE:
Depending on the file system, a file can have an internal structure that
is convenient for particular applications. In addition, files can be organized
into hierarchical or more complex structure to reflect the relationship among
files.
Any file system provides not only a means to store data organized as
files, but a collection of functions that can be performed on files. Typical
operations include the following:
 CREATE:
A new file is defined and positioned within the structure of files.
 DELETE:
A file is removed from the file structure and destroyed.
 OPEN
An existing file is declared to be ‘opened” by a process, allowing the
process to perform functions on the file.
 CLOSE
The file is closed with respect to a process, so that the process no
longer may perform functions on the file, until the process opens the file again.
 READ
A process reads all or a portion of the data in a file.
 WRITE
A process updates a file, either by adding new data that expands the size
of the file or by changing the values of existing data items in the file. Typically,
a file system maintains a set of attributes associated with the file. These include
owner, creation time, time last modified, access privileges, and so on.

68
5.2 FILE STRUCTURE
Four terms are in common use when discussing files:
 Field
 Record
 File
 Database
FIELD
A field is the basic element of data. An individual field contains a single
value, such as employee’s last name, a date or the value of a sensor reading. It
is characterized by its length and data type.
RECORD
A record is a collection of related fields that can be treated as a unit by
some application program. For example, an employee record would contain
such field as name, social security number, job classification, date of hire, and
so on.
FILE
A file is a collection of similar records. The file is treated as a single
entity by user and application and may be referenced by name. Files have file
name and may be created and deleted. Access control restrictions usually apply
at the file level.
DATABASE
A database is a collection of related data. The essential aspect of a
database is that the relationships that exist among elements of data are explicit
and that the database is designed for use by a number of different applications.
A database may contain all of the information related to an organization or
project, such as business or a scientific study. The database itself consists of
one or more types of files.
5.3 FILE ORGANIZATION AND ACCESS
File organization refers to the logical structuring of the records as
determined by the way in they are accessed.
In choosing a file organization, several criteria are important:
 Short access time
 Ease of update
 Economy of storage
 Simple maintenance
 Reliability
The relative priority of these criteria will depend on the applications
that will use the file. For example, if a file is only to be processed in batch
mode, with all of the records accessed every time, then rapid access for
retrieval of a single record is of minimal concern. A file stored on CD-ROM
will never be updated, and so ease of update is not an issue.

69
 These criteria may conflict. For example, for economy of storage, there
should be minimum redundancy in the data. On the other hand, redundancy is a
primary means of increasing the speed of access to data. An example of this is
the use of indexes.
The number of alternative file organizations that have been
implemented or just proposed is unmanageably large, even for a book devoted
to file system. In this brief survey, we will outline five fundamental
organizations. Most structures used in actual systems either fall into one of
these categories or can be implemented with a combination of these
organizations. The five organizations, the first four of which are depicted.
 The File
 The sequential file
 The indexed sequential file
 The indexed file
 The direct, or hashed, file
THE FILE
The least-complicated form of the file organization may be termed the
pile. Data are collected in the order in which they arrive. Each record consists
of one burst of data. The purpose of the pile is simply to accumulate the mass
of data and save it. Records may have different fields, or similar fields in
different orders. Thus, each field should be self-describing, including a field
name as well as a value. The length of each field must be implicitly indicated
by delimiters, explicitly included as a subfield, or known as default for that
field type.
THE SEQUENTIAL FILE
The most common form of file structure is the sequential file. In this
type of file, a fixed format is used for records. All records are of the same
length, consisting of the same number of fixed-length fields in a particular
order. Because the length and position of each field are known, only the values
of fields need to be stored; the field name and length for each field are
attributes of the file structure.
One particular field, usually the first in each record, is referred to as the
key field. The key field uniquely identifies the record; thus key values for
different records are always different. Further, the records are stored in key
sequence: alphabetical order for a text key, and numerical order for a numerical
key.
THE INDEXED SEQUENTIAL FILE
A popular approach to overcoming the disadvantages of the sequential
file is the indexed sequential file. The indexed sequential file maintains the key
characteristic of the sequential file: records are organized in sequence based on
a key field. Two features are added: an index to the file to support random
access, and an overflow file. The index provides a lookup capability to reach
quickly the vicinity of a desired record. The overflow file is similar to the log

70
file used with a sequential file but is integrated so that a record in the overflow
files is located by following a pointer from its predecessor record.
THE INDEXED FILE
The indexed sequential file retain one limitation of the sequential file:
effective processing is limited to that which is based on a single field of the
file. When it is necessary to search for a record on the basis of some other
attribute than the key field, both forms of sequential file are inadequate. In
some application, this flexibility is desirable.
THE DIRECT OR HASHED FILE
The direct, or hashed, file exploit the capability found on disks to access
directly and block of a known address. As with sequential and indexed
sequential files, a key field is required in each record in each record. However,
there is no concept of sequential ordering here.
5.4 FILE DIRECTORIES
CONTENT
Associated with any file management system and collection of files is a
file directory. The directory contains information about the files, including
attributes, location, and ownership. Much of this information especially that
concerned with storage is managed by the operating system. The directory is
itself a file, accessible by various file management routines. Although some of
the information in directories is available to users and applications, this is
generally provided indirectly by system routine.
STRUCTURE
Some of the information may be stored in a header record associated
with the file; this reduces the amount of storage required for the directory,
making it easier to keep all or much of the directory in main memory to
improve speed.
The simplest form of structure for a directory is that of a list of entries,
one for each file. This structure could be represented by a simple sequential
file, with the name of the file serving as the key. In some earlier single-user
system, this technique has been used. However, it is inadequate when multiple
users share a system and even for single user with many files.
To understand the requirements for a file structure, it is helpful to consider the
types of operations that may be performed on the directory:
 SEARCH: When a user or application references a file, the directory
must be searched to find the entry corresponding to that file.
 CREATE FILE: When a new file is created, an entry must be added to
the directory
 DELETE FILE: when a file is deleted, an entry must be removed from
the directory
 LIST DIRECTORY: All or a portion of the directory may be
requested. Generally, this request is made by a user and result in a

71
 listing of all files owned by that user, plus some of the attributes of each
file.
 UPDATE DIRECTORY: Because some file attributes are stored in the
directory, a change in one of these attribute requires a change in the
corresponding directory entry.
NAMING
User need to be able to refer to a file by a symbolic name. Clearly, each
file in the system must have a unique name in order that file references be
unambiguous. On the other hand, it is an unacceptable burden on users to
require that they provide unique names, especially in a shared system.
The user of a tree-structured directory minimizes the difficulty in
assigning unique names. Any file in the system can be located by following a
path from the root or master directory down various branches until the file is
reached. The series of directory names, culminating in the file name itself,
constitutes a pathname for the file.
5.5 FILE SHARING
In a multi-user system, there is almost always a requirement for
allowing files to be shared among a number of users. Two issues arise: access
rights and the management of simultaneous access.
ACCESS RIGHTS
The file system should provide a flexible tool for allowing extensive file
sharing among users. The file system should provide a number of options so
that the way in which a particular file is accessed can be controlled. Typically,
users or groups of users are granted certain access rights to a file. A wide range
of access rights has been used. The following list is representative of access
rights that can be assigned to a particular user for a particular file:
 None: The user may not even learn of the existence of the file, much less
access it. To enforce this restriction, the user would not be allowed to read
the user directory that includes this file.
 Knowledge: The user can determine that the file exists and who its owner
is. The user is then able to petition the owner for additional access rights.
 Execution: The user can load and execute a program but cannot copy it.
Proprietary program are often made accessible with this restriction.
 Reading: The user can read the file for any purpose, including copying and
execution. Some systems are able to enforce a distinction between viewing
and copying. In the former case, the contents of the file can be displayed to
the user, but the user has no means for making a copy.
 Appending: The user can add data to the file, often only at the end, but
cannot modify or delete any of the file’s content. This right is useful in
collecting data from a number of sources.
 Updating: The user can modify, delete, and add to the file data. This is
normally includes writing the file initially, rewriting it completely or in

72
 part, and removing all or a portion of the data. some system distinguish
among different degrees of updating.
 DELETION: the user can delete the files from the file system.
5.6 RECORD BLOCKING
 FIXED BLOCKING: Fixed-length records are used, and an integral
number of records is stored in a block. There may be unused space at
the end of each block. This is referred to as internal fragmentation.
 VARIABLE-LENGTH SPANNED BLOCKING: Variable-length
records are used and are packed into blocks with no unused space.
Thus, some records must span two blocks, with the continuation
indicated by a pointer to the successor block.
 VARIABLE-LENGTH UNSPANNED BLOCKING: Variable-length
records are used, but spanning is not employed. These are wasted space
in most blocks because of the inability to use the remainder of a block if
the next record is larger than the remaining unused space.
5.7 SECONDARY STORAGE MANAGEMENT
On secondary storage, a file consists of a collection of blocks. The
operating system or file management system is responsible for allocating
blocks to files. This raises two management issues. First, space on secondary
storage must be allocated to files, and second, it is necessary to keep track of
the space available for allocation. We will see that these two tasks are related;
that is, the approach taken for file allocation may influence the approach taken
for the free space management. Further, we will see that there is an interaction
between file structure and allocation policy.
5.7.1 File Allocation
Several issues are involved in file allocation:
1. When a new file is created, is the maximum space required for the file
allocated at once?
2. Space is allocated to a file as one or more contiguous units, which we
shall refer to as portions. The size of a portion can range from a single
block to the entire file, what size of portion should be used for file
allocation?
3. What sort of data structure or table is used to keep track of the portion
assigned to a file? An example of such a structure is a file allocation
table (FAT), found on DOS and some other systems.
5.7.2 Pre allocation versus Dynamic Allocation
A pre allocation policy requires that the maximum size of a file be
declared at the time of the file creation request. In a number of cases, such as
the transfer of a file from another system over the communications network,
this value can be reliably estimated. However, for many applications, it is
difficult if not impossible to estimate reliably the maximum potential size of
the file. In those cases, user and application programmers would tend to
overestimate file size so as not to run out space. This clearly is wasteful from

73
the point of view of secondary storage allocation. Thus, there are advantages to
the use of dynamic allocation, which allocates space to a file in portions as
needed.
Portion size
The second issue listed is that of the size of the potion allocated to a
file. At one extreme, a potion large enough to hold the entire file is allocated to
a file. At one extreme, a portion large enough to the entire file is allocated .At
the other extreme, space on the disk is allocated one block at a time .In
choosing a position size, there is a tradeoff between efficiency from the view of
a single file verses overall system efficiency.
1. Contiguity of space increase performance, especially for Retrieve Next
operations, and greatly for transactions running in a transaction oriented
operating system.
2. Having a large number of small portions increasing the size of tables
needed to manage the allocation information.
3. Having fixed-size portion (for example, blocks) simplifies the
reallocation of space.
4. Having variable-size or small fixed-size portion minimizes waste of
unused storage due to over allocation. Of course, these items interact
and must be considered together. The result is that there are two major
alternatives:
 Variable, large contiguous portion: this will provide better
performance. The variable size avoids waste, and the file allocation
tables are small. However, space is hard to reuse.
 Blocks: Small fixed portions provide greater flexibility. They may
require large tables or complex structures for their allocation.
Contiguity has been abandoned as a primary goal; blocks are allocated
as needed.
The following are possible alternative strategies:
 First fit: Choose the first unused contiguous group of blocks of
sufficient size from a free block list.
 Best fit: Choose the smallest unused group that is of sufficient size.
 Nearest fit: Choose the unused group of sufficient size that is closest to
the previous allocation for the file to increase locality.
File allocation methods having looked at the issues of reallocation
versus dynamic allocation and portion size, we are in a position to consider
specific file allocation methods. Three methods are in common use:
contiguous, chained, and indexed. Table 12.3 summarizes some of the
characteristics of each method.
With contiguous allocation, a single contiguous set of blocks is
allocated to a file at the time of file creation. Thus, this is a reallocation
strategy, using variable-size portions. The file allocation table needs just a
single entry for each file, showing the starting block and the length of the file.

74
Contiguous allocation is the best from the point of view of the individual
sequential file. Multiple blocks can be read in at a time to improve I/O
performance for sequential processing. It is also easy to retrieve a single block.
Indexed allocation addresses many of the problems of contiguous and
chained allocation. In this case, the file allocation table contains a separate one
level index for each file; the index has one entry for each portion allocated to
the file. Typically, the file indexes are not physically stored as part of the file
allocation table. Rather, the file index for a file is kept in a separate block and
the entry for the file in the file allocation table points to that block. Allocation
may be on the basis of either fixed-size blocks.
5.7.3 FREE SPACE MANAGEMENT
Just as the space that is allocated to files must be managed, so the space
that is not currently allocated to any file must be managed. To perform any of
the file allocation techniques described previously, it is necessary to know what
blocks on the disk are available. Thus we need a disk allocation table in
addition to a file allocation table.

75
 NOTES
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..
…………………………………………………………………….……………..

76