MCS-203

Operating Systems
Indira Gandhi National Open University
School of Computer and Information
Sciences (SOCIS)

UT/OUTP SECURITY
INP AGEMEUT
M AN NT

E M ORY MENT TRO N

G
M
A N AGE UBLE SHOOTI
M
DEV
MANAGE M A N A I CE
E SS ME GE
ROC N T
ME
N
P T

Block Title 1
 MCS-203
Operating Systems
Indira Gandhi
National Open University
School of Computer and
Information Sciences

Block

1
INTRODUCTION TO OPERATING SYSTEMS
AND PROCESS MANAGEMENT
UNIT 1
Operating System: An Overview 7
UNIT 2
Processes 29
UNIT 3
Interprocess Communication and Synchronization 57
UNIT 4
Deadlocks 81
PROGRAMME/COURSE DESIGN COMMITTEE
Prof. Sanjeev K. Aggarwal, IIT, Kanpur Shri Sanjeev Thakur
Shri Navneet Aggarwal Amity School of Computer Sciences, Noida
Trinity BPM, New Delhi Shri Amrit Nath Thulal
Prof. M. Balakrishnan, IIT, Delhi Amity School of Engineering and Technology
Prof. Pandurangan, C., IIT, Madras New Delhi
Ms. Bhoomi Gupta Dr. Om Vikas (Retd), Ex-Sr. Director,
Sirifort College of Computer and Technology Ministry of ICT, Delhi
Management, New Delhi Shri Vishwakarma
Shri Manoj Kumar Gupta Amity School of Engineering and Technology
Keane India Ltd., New Delhi New Delhi
Shri Sachin Gupta Prof (Retd) S. K. Gupta, IIT Delhi
Delhi Institute of Advanced Studies, Prof. T.V. Vijaya Kumar, Dean, SC&SS,
New Delhi JNU, New Delhi
Prof. Harish Karnick, IIT, Kanpur Prof. Ela Kumar, Dean, CSE, IGDTUW, Delhi
Shri Anil Kumar Prof. Gayatri Dhingra, GVMITM, Sonipat
Amity School of Engineering and Technology
New Delhi Sh. Milind Mahajani Vice President,
Impressico Business Solutions, Noida, UP
Dr. Kapil Kumar, IIMT, Meerut
D r . Sachin Kumar, Prof. V. V. Subrahmanyam, Director
SOCIS, New Delhi
CCS University, Meerut
Prof. P. V. Suresh,
Ms. Manjulata
Amity School of Engineering and Technology SOCIS, IGNOU, New Delhi
New Delhi Dr. Shashi Bhushan
Shri Ajay Rana SOCIS, IGNOU, New Delhi
Amity School of Computer Sciences, Noida Shri Akshay Kumar, Associate Prof.
Dr. Divya Sharma SOCIS, IGNOU, New Delhi
Bharati College, Delhi Shri M. P. Mishra, Associate Prof.
Shri Neeraj Sharma SOCIS, IGNOU, New Delhi
Havard Institute of Management Technology Dr. Sudhansh Sharma, Asst. Prof
Noida SOCIS, IGNOU, New Delhi

BLOCK PREPARATION TEAM

Prof. D.P. Vidyarthi (Content Editor) Shri Sachin Gupta
Jawaharlal Nehru University Delhi Institute of Advanced Studies
New Delhi New Delhi
Shri Akash Bajpai Prof. V.V. Subrahmanyam
Deptt. of Technical Education SOCIS, IGNOU
Uttar Pradesh
Dr. Nandini Sahu
Shri Kapil Kumar IIMT, (Language Editors)
Meerut &
Ms. Malathy. A
School of Humanities
IGNOU

Course Coordinator: Prof. V. V. Subrahmanyam

(The Units of Block-1, Unit 1 to Unit-4 were adopted from MCS-041 Operating Systems)

PRINT PRODUCTION
Mr. Tilak Raj
Assistant Registrar,
MPDD, IGNOU, New Delhi

July, 2021
© Indira Gandhi National Open University, 2021
ISBN : 978-93-91229-15-3
All rights reserved. No part of this work may be reproduced in any form, by mimeograph or any other
means, without permission in writing from the Indira Gandhi National Open University.
Further information on the Indira Gandhi National Open University courses may be obtained from the
University’s ofce at Maidan Garhi, New Delhi-110068.
Printed and published on behalf of the Indira Gandhi National Open University, New Delhi by the
Registrar, MPDD, IGNOU, New Delhi
Laser Typesetting : Akashdeep Printers, 20-Ansari Road, Daryaganj, New Delhi-110002
Printed at : Akashdeep Printers, 20-Ansari Road, Daryaganj, New Delhi-110002
COURSE INTRODUCTION
The most fundamental of all system programs is the operating system, which controls
computer’s resources and provides the base on which application programs may be
written. A modern operating system manages one or more processors, processes,
files, a hierarchy of memory, clocks, disks, network interfaces, I/O devices, protection
and security. The operating system’s purpose is to provide an orderly and controlled
allocation of all of these resources among the programs competing for them.
This is a core course on Operating Systems covering the broader perspective of its
operation. Each unit includes presentation of the contents with examples and solved
problems. This course introduces the key mechanisms of the operating system like
process management, memory management, file systems, I/O management and
protection and security. The whole course is organised into 4 Blocks.
Block 1 covers the Introduction to Operating Systems, the role of processes, their
creation, process scheduling, interprocess communication and synchronization and
deadlocks.
Block 2 covers the study of storage management: static and dynamic allocation, paging
and segmentation, virtual memory and demand paging, page replacement of algorithms
and memory caches and their effect on performance followed by the File management
concepts, such as input/output hardware and software, files, directories and access
mechanisms, file allocation and access algorithms and performance. Finally, the
increasingly important areas of protection and security are discussed like the goals,
authentication, access mechanisms, protection domains, access control lists and
capabilities, and monitoring.
Block 3 covers the advanced topics in Operating Systems like Multiprocessor systems.
Distributed systems and Mobile Operating Systems.
Block 4 covers the case studies on Windows 10, Linux, Android and iOS.
There is a lab component associated with this course (i.e., Section-1 Windows 10 and
Section-2 Linux of MCSL-204 course).
BLOCK INTRODUCTION
The objective of this block is to familiarise you with the issues involved in the design
and implementation of modern operating systems. The course does not concentrate on
any particular operating system or hardware platform. The concepts discussed are
applicable to a variety of systems.
The block is organised into 4 units:
Unit 1 covers the introduction to operating systems;
Unit 2 covers the concept of processes, process states, process switch, threads, CPU
scheduling, various scheduling algorithms and their performance criteria;
Unit 3 covers the interprocess communication, concurrency and synchronization aspects
of the processes, and
Unit 4 covers the deadlocks, conditions for the deadlock, deadlock prevention,
avoidance and recovery.
Introduction to Operating
Systems and Process
Management

6
 Operating System:
UNIT 1 OPERATING SYSTEM : AN An Overview

OVERVIEW
Structure

1.1 Introduction
1.2 Objectives
1.3 What is an Operating System?
1.4 Goals of an Operating System
1.5 Generations of Operating Systems
1.5.1 0th Generation
1.5.2 First Generation (1951-1956)
1.5.3 Second Generation (1956-1964)
1.5.4 Third Generation (1964-1979)
1.5.5 Fourth Generation (1979-Present)
1.6 Types of Operating Systems
1.6.1 Batch Processing Operating System
1.6.2 Time Sharing
1.6.3 Real Time Operating System (RTOS)
1.6.4 Multiprogramming Operating System
1.6.5 Multiprocessing System
1.6.6 Networking Operating System
1.6.7 Distributed Operating System
1.6.8 Operating Systems for Embedded Devices
1.7 Desirable Qualities of OS
1.8 Operating Systems : Some Examples
1.8.1 DOS
1.8.2 UNIX
1.8.3 Windows
1.8.4 Macintosh
1.9 Functions of OS
1.9.1 Process Management
1.9.2 Memory Management
1.9.3 Secondary Storage Management
1.9.4 I/O Management
1.9.5 File Management
1.9.6 Protection
1.9.7 Networking
1.9.8 Command Interpretation
1.10 Summary
1.11 Solutions/Answers
1.12 Further Readings 7
Introduction to Operating
Systems and Process 1.1 INTRODUCTION
Management
Computer software can be divided into two main categories: application software and
system software. Application software consists of the programs for performing tasks
particular to the machine’s utilization. This software is designed to solve a particular
problem for users. Examples of application software include spreadsheets, database
systems, desktop publishing systems, program development software, and games.
On the other hand, system software is more transparent and less noticed by the typical
computer user. This 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. System software acts as an interface
between the hardware of the computer and the application software that users need to
run on the computer. The most important type of system software is the operating
system.
An Operating System (OS) is a collection of programs that acts as an interface
between a user of a computer and the computer hardware. The purpose of an operating
system is to provide an environment in which a user may execute the programs.
Operating Systems are viewed as resource managers. The main resource is the computer
hardware in the form of processors, storage, input/output devices, communication
devices, and data. Some of the operating system functions are: implementing the user
interface, sharing hardware among users, allowing users to share data among themselves,
preventing users from interfering with one another, scheduling resources among users,
facilitating input/output, recovering from errors, accounting for resource usage, facilitating
parallel operations, organizing data for secure and rapid access, and handling network
communications.
This unit presents the definition of the operating system, goals of the operating system,
generations of OS, different types of OS and functions of OS.

1.2 OBJECTIVES
After going through this unit, you should be able to:
 understand the purpose of an operating system;
 describe the general goals of an operating system;
 discuss the evolution of operating systems;
 describe various functions performed by the OS;
 list, discuss and compare various types of OS, and
 describe various structures of operating system.

1.3 WHAT IS AN OPERATING SYSTEM?

In a computer system, we find four main components: the hardware, the operating
system, the application software and the users. In a computer system the hardware
88 provides the basic computing resources. The applications programs define the way in
which these resources are used to solve the computing problems of the users. The Operating System:
An Overview
operating system controls and coordinates the use of the hardware among the various
systems programs and application programs for the various users.
We can view an operating system as a resource allocator. A computer system has
many resources (hardware and software) that may be required to solve a problem:
CPU time, memory space, files storage space, input/output devices etc. The operating
system acts as the manager of these resources and allocates them to specific programs
and users as necessary for their tasks. Since there may be many, possibly conflicting,
requests for resources, the operating system must decide which requests are allocated
resources to operate the computer system fairly and efficiently.
An operating system is a control program. This program controls the execution of
user programs to prevent errors and improper use of the computer. Operating systems
exist because: they are a reasonable way to solve the problem of creating a usable
computing system. The fundamental goal of a computer system is to execute user
programs and solve user problems.
While there is no universally agreed upon definition of the concept of an operating
system, the following is a reasonable starting point:
A computer’s operating system is a group of programs designed to serve two basic
purposes:
 To control the allocation and use of the computing system’s resources among
the various users and tasks, and
 To provide an interface between the computer hardware and the programmer
that simplifies and makes feasible the creation, coding, debugging, and
maintenance of application programs.
An effective operating system should accomplish the following functions:
 Should act as a command interpreter by providing a user friendly environment.
 Should facilitate communication with other users.
 Facilitate the directory/file creation along with the security option.
 Provide routines that handle the intricate details of I/O programming.
 Provide access to compilers to translate programs from high-level languages
to machine language
 Provide a loader program to move the compiled program code to the
computer’s memory for execution.
 Assure that when there are several active processes in the computer, each
will get fair and non-interfering access to the central processing unit for
execution.
 Take care of storage and device allocation.
 Provide for long term storage of user information in the form of files.
 Permit system resources to be shared among users when appropriate, and be
protected from unauthorised or mischievous intervention as necessary.
9
Introduction to Operating Though systems programs such as editors and translators and the various utility programs
Systems and Process
Management (such as sort and le transfer program) are not usually considered part of the operating
system, the operating system is responsible for providing access to these system
resources.
The abstract view of the components of a computer system and the positioning of OS
is shown in the Figure 1.

Figure 1: Abstract View of the Components of a Computer System

1.4 GOALS OF AN OPERATING SYSTEM

The primary objective of a computer is to execute an instruction in an efcient manner
and to increase the productivity of processing resources attached with the computer
system such as hardware resources, software resources and the users. In other words,
we can say that maximum CPU utilisation is the main objective, because it is the main
device which is to be used for the execution of the programs or instructions. We can
brief the goals as:
· The primary goal of an operating system is to make the computer convenient
to use.
· The secondary goal is to use the hardware in an efcient manner.

1.5 GENERATIONS OF OPERATING SYSTEMS

We have studied the denition and the goals of the operating systems.

Operating systems have been evolving over the years. We will briey look at this
development of the operating systems with respect to the evolution of the hardware
/ architecture of the computer systems in this section. Since operating systems have
historically been closely tied with the architecture of the computers on which they run,
we will look at successive generations of computers to see what their operating systems
were like. We may not exactly map the operating systems generations to the generations
of the computer, but roughly it provides the idea behind them.

We can roughly divide them into ve distinct generations that are characterized by

10
hardware component technology, software development, and mode of delivery of Operating System:
An Overview
computer services.

1.4.1 0th Generation

The term 0th generation is used to refer to the period of development of computing,
which predated the commercial production and sale of computer equipment. We
consider that the period might be way back when Charles Babbage invented the
Analytical Engine. Afterwards the computers by John Atanasoff in 1940; the Mark I,
built by HowardAiken and a group of IBM engineers at Harvard in 1944; the ENIAC,
designed and constructed at the University of Pencylvania by Wallace Eckert and John
Mauchly and the EDVAC, developed in 1944-46 by John Von Neumann, Arthur
Burks, and Herman Goldstine (which was the first to fully implement the idea of the
stored program and serial execution of instructions) were designed. The development
of EDVAC set the stage for the evolution of commercial computing and operating
system software. The hardware component technology of this period was electronic
vacuum tubes.
The actual operation of these early computers took place without the benefit of an
operating system. Early programs were written in machine language and each
contained code for initiating operation of the computer itself.
The mode of operation was called “open-shop” and this meant that users signed up for
computer time and when a user’s time arrived, the entire (in those days quite large)
computer system was turned over to the user. The individual user (programmer) was
responsible for all machine set up and operation, and subsequent clean-up and
preparation for the next user. This system was clearly inefficient and dependent on the
varying competencies of the individual programmer as operators.

1.4.2 First Generation (1951-1956)

The first generation marked the beginning of commercial computing, including the
introduction of Eckert and Mauchly’s UNIVAC I in early 1951, and a bit later, the
IBM 701 which was also known as the Defence Calculator. The first generation was
characterised again by the vacuum tube as the active component technology.
Operation continued without the benefit of an operating system for a time. The mode
was called “closed shop” and was characterised by the appearance of hired operators
who would select the job to be run, initial program load the system, run the user’s
program, and then select another job, and so forth. Programs began to be written in
higher level, procedure-oriented languages, and thus the operator’s routine expanded.
The operator now selected a job, ran the translation program to assemble or compile
the source program, and combined the translated object program along with any existing
library programs that the program might need for input to the linking program, loaded
and ran the composite linked program, and then handled the next job in a similar
fashion.
Application programs were run one at a time, and were translated with absolute computer
addresses that bound them to be loaded and run from these reassigned storage addresses
set by the translator, obtaining their data from specific physical I/O device. There was
no provision for moving a program to different location in storage for any reason.
Similarly, a program bound to specific devices could not be run at all if any of these
devices were busy or broken. 11
Introduction to Operating The inefficiencies inherent in the above methods of operation led to the development of
Systems and Process
Management the mono-programmed operating system, which eliminated some of the human
intervention in running job and provided programmers with a number of desirable
functions. The OS consisted of a permanently resident kernel in main storage, and a
job scheduler and a number of utility programs kept in secondary storage. User
application programs were preceded by control or specification cards (in those day,
computer program were submitted on data cards) which informed the OS of what
system resources (software resources such as compilers and loaders; and hardware
resources such as tape drives and printer) were needed to run a particular application.
The systems were designed to be operated as batch processing system.
These systems continued to operate under the control of a human operator who initiated
operation by mounting a magnetic tape that contained the operating system executable
code onto a “boot device”, and then pushing the IPL (Initial Program Load) or “boot”
button to initiate the bootstrap loading of the operating system. Once the system was
loaded, the operator entered the date and time, and then initiated the operation of the
job scheduler program which read and interpreted the control statements, secured the
needed resources, executed the first user program, recorded timing and accounting
information, and then went back to begin processing of another user program, and so
on, as long as there were programs waiting in the input queue to be executed.
The first generation saw the evolution from hands-on operation to closed shop operation
to the development of mono-programmed operating systems. At the same time, the
development of programming languages was moving away from the basic machine
languages; first to assembly language, and later to procedure oriented languages, the
most significant being the development of FORTRAN by John W. Backus in 1956.
Several problems remained, however, the most obvious was the inefficient use of system
resources, which was most evident when the CPU waited while the relatively slower,
mechanical I/O devices were reading or writing program data. In addition, system
protection was a problem because the operating system kernel was not protected
from being overwritten by an erroneous application program. Moreover, other user
programs in the queue were not protected from destruction by executing programs.

1.4.3 Second Generation (1956-1964)

The second generation of computer hardware was most notably characterised by
transistors replacing vacuum tubes as the hardware component technology. In addition,
some very important changes in hardware and software architectures occurred during
this period. For the most part, computer systems remained card and tape-oriented
systems. Significant use of random access devices, that is, disks, did not appear until
towards the end of the second generation. Program processing was, for the most part,
provided by large centralised computers operated under mono-programmed batch
processing operating systems.
The most significant innovations addressed the problem of excessive central processor
delay due to waiting for input/output operations. Recall that programs were executed
by processing the machine instructions in a strictly sequential order. As a result, the
CPU, with its high speed electronic component, was often forced to wait for completion
of I/O operations which involved mechanical devices (card readers and tape drives)
that were order of magnitude slower. This problem led to the introduction of the data
channel, an integral and special-purpose computer with its own instruction set, registers,
12 and control unit designed to process input/output operations separately and
asynchronously from the operation of the computer’s main CPU near the end of the Operating System:
An Overview
first generation, and its widespread adoption in the second generation.
The data channel allowed some I/O to be buffered. That is, a program’s input data
could be read “ahead” from data cards or tape into a special block of memory called
a buffer. Then, when the user’s program came to an input statement, the data could be
transferred from the buffer locations at the faster main memory access speed rather
than the slower I/O device speed. Similarly, a program’s output could be written another
buffer and later moved from the buffer to the printer, tape, or card punch. What made
this all work was the data channel’s ability to work asynchronously and concurrently
with the main processor. Thus, the slower mechanical I/O could be happening
concurrently with main program processing. This process was called I/O overlap.
The data channel was controlled by a channel program set up by the operating system
I/O control routines and initiated by a special instruction executed by the CPU. Then,
the channel independently processed data to or from the buffer. This provided
communication from the CPU to the data channel to initiate an I/O operation. It remained
for the channel to communicate to the CPU such events as data errors and the completion
of a transmission. At first, this communication was handled by polling – the CPU
stopped its work periodically and polled the channel to determine if there is any message.
Polling was obviously inefficient (imagine stopping your work periodically to go to the
post office to see if an expected letter has arrived) and led to another significant innovation
of the second generation – the interrupt. The data channel was able to interrupt the
CPU with a message – usually “I/O complete.” Infact, the interrupt idea was later
extended from I/O to allow signalling of number of exceptional conditions such as
arithmetic overflow, division by zero and time-run-out. Of course, interval clocks were
added in conjunction with the latter, and thus operating system came to have a way of
regaining control from an exceptionally long or indefinitely looping program.
These hardware developments led to enhancements of the operating system. I/O and
data channel communication and control became functions of the operating system,
both to relieve the application programmer from the difficult details of I/O programming
and to protect the integrity of the system to provide improved service to users by
segmenting jobs and running shorter jobs first (during “prime time”) and relegating
longer jobs to lower priority or night time runs. System libraries became more widely
available and more comprehensive as new utilities and application software components
were available to programmers.
In order to further mitigate the I/O wait problem, system were set up to spool the input
batch from slower I/O devices such as the card reader to the much higher speed tape
drive and similarly, the output from the higher speed tape to the slower printer. In this
scenario, the user submitted a job at a window, a batch of jobs was accumulated and
spooled from cards to tape “off line,” the tape was moved to the main computer, the
jobs were run, and their output was collected on another tape that later was taken to a
satellite computer for off line tape-to-printer output. User then picked up their output
at the submission windows.
Toward the end of this period, as random access devices became available, tape-
oriented operating system began to be replaced by disk-oriented systems. With the
more sophisticated disk hardware and the operating system supporting a greater portion
of the programmer’s work, the computer system that users saw was more and more
removed from the actual hardware-users saw a virtual machine. 13
Introduction to Operating The second generation was a period of intense operating system development.
Systems and Process
Management Also it was the period for sequential batch processing. But the sequential processing of
one job at a time remained a significant limitation. Thus, there continued to be low
CPU utilisation for I/O bound jobs and low I/O device utilisation for CPU bound jobs.
This was a major concern, since computers were still very large (room-size) and
expensive machines. Researchers began to experiment with multiprogramming and
multiprocessing in their computing services called the time-sharing system.Anoteworthy
example is the Compatible Time Sharing System (CTSS), developed at MIT during
the early 1960s.

1.4.4 Third Generation (1964-1979)

The third generation officially began in April 1964 with IBM’s announcement of its
System/360 family of computers. Hardware technology began to use integrated circuits
(ICs) which yielded significant advantages in both speed and economy.
Operating system development continued with the introduction and widespread adoption
of multiprogramming. This marked first by the appearance of more sophisticated I/O
buffering in the form of spooling operating systems, such as the HASP (Houston
Automatic Spooling) system that accompanied the IBM OS/360 system. These systems
worked by introducing two new systems programs, a system reader to move input
jobs from cards to disk, and a system writer to move job output from disk to printer,
tape, or cards. Operation of spooling system was, as before, transparent to the computer
user who perceived input as coming directly from the cards and output going directly
to the printer.
The idea of taking fuller advantage of the computer’s data channel I/O capabilities
continued to develop. That is, designers recognised that I/O needed only to be initiated
by a CPU instruction – the actual I/O data transmission could take place under control
of separate and asynchronously operating channel program. Thus, by switching control
of the CPU between the currently executing user program, the system reader program,
and the system writer program, it was possible to keep the slower mechanical I/O
device running and minimizes the amount of time the CPU spent waiting for I/O
completion. The net result was an increase in system throughput and resource utilisation,
to the benefit of both user and providers of computer services.
This concurrent operation of three programs (more properly, apparent concurrent
operation, since systems had only one CPU, and could, therefore execute just one
instruction at a time) required that additional features and complexity be added to the
operating system. First, the fact that the input queue was now on disk, a direct access
device, freed the system scheduler from the first-come-first-served policy so that it
could select the “best” next job to enter the system (looking for either the shortest job
or the highest priority job in the queue). Second, since the CPU was to be shared by
the user program, the system reader, and the system writer, some processor allocation
rule or policy was needed. Since the goal of spooling was to increase resource utilization
by enabling the slower I/O devices to run asynchronously with user program processing,
and since I/O processing required the CPU only for short periods to initiate data
channel instructions, the CPU was dispatched to the reader, the writer, and the program
in that order. Moreover, if the writer or the user program was executing when something
became available to read, the reader program would preempt the currently executing
program to regain control of the CPU for its initiation instruction, and the writer program
14 would preempt the user program for the same purpose. This rule, called the static
priority rule with preemption, was implemented in the operating system as a system Operating System:
An Overview
dispatcher program.
The spooling operating system in fact had multiprogramming since more than one
program was resident in main storage at the same time. Later this basic idea of
multiprogramming was extended to include more than one active user program in
memory at time. To accommodate this extension, both the scheduler and the dispatcher
were enhanced. The scheduler became able to manage the diverse resource needs of
the several concurrently active used programs, and the dispatcher included policies for
allocating processor resources among the competing user programs. In addition, memory
management became more sophisticated in order to assure that the program code for
each job or at least that part of the code being executed, was resident in main storage.
The advent of large-scale multiprogramming was made possible by several important
hardware innovations such as:
 The widespread availability of large capacity, high-speed disk units to
accommodate the spooled input streams and the memory overflow together
with the maintenance of several concurrently active program in execution.
 Relocation hardware which facilitated the moving of blocks of code within
memory without any undue overhead penalty.
 The availability of storage protection hardware to ensure that user jobs are
protected from one another and that the operating system itself is protected
from user programs.
 Some of these hardware innovations involved extensions to the interrupt system
in order to handle a variety of external conditions such as program malfunctions,
storage protection violations, and machine checks in addition to I/O interrupts.
In addition, the interrupt system became the technique for the user program
to request services from the operating system kernel.
 The advent of privileged instructions allowed the operating system to maintain
coordination and control over the multiple activities now going on with in the
system.
Successful implementation of multiprogramming opened the way for the development
of a new way of delivering computing services-time-sharing. In this environment, several
terminals, sometimes up to 200 of them, were attached (hard wired or via telephone
lines) to a central computer. Users at their terminals, “logged in” to the central system,
and worked interactively with the system. The system’s apparent concurrency was
enabled by the multiprogramming operating system. Users shared not only the system
hardware but also its software resources and file system disk space.
The third generation was an exciting time, indeed, for the development of both computer
hardware and the accompanying operating system. During this period, the topic of
operating systems became, in reality, a major element of the discipline of computing.

1.4.5 Fourth Generation (1979 – Present)

The fourth generation is characterized by the appearance of the personal computer
and the workstation. Miniaturization of electronic circuits and components continued
and large scale integration (LSI), the component technology of the third generation,
was replaced by very large scale integration (VLSI), which characterizes the fourth 15
Introduction to Operating generation. VLSI with its capacity for containing thousands of transistors on a small
Systems and Process
Management chip, made possible the development of desktop computers with capabilities exceeding
those that lled entire rooms and oors of building just twenty years earlier.
The operating systems that control these desktop machines have brought us back in a
full circle, to the open shop type of environment where each user occupies an entire
computer for the duration of a job’s execution. This works better now, not only because
the progress made over the years has made the virtual computer resulting from the
operating system/hardware combination so much easier to use, or, in the words of the
popular press “user-friendly.”
However, improvements in hardware miniaturisation and technology have evolved so
fast that we now have inexpensive workstation – class computers capable of supporting
multiprogramming and time-sharing. Hence the operating systems that supports today’s
personal computers and workstations look much like those which were available for
the minicomputers of the third generation. Examples are Microsoft’s DOS for IBM-
compatible personal computers and UNIX for workstation.
However, many of these desktop computers are now connected as networked or
distributed systems. Computers in a networked system each have their operating systems
augmented with communication capabilities that enable users to remotely log into any
system on the network and transfer information among machines that are connected to
the network. The machines that make up distributed system operate as a virtual single
processor system from the user’s point of view; a central operating system controls
and makes transparent the location in the system of the particular processor or
processors and le systems that are handling any given program.

F Check Your Progress 1

1) What are the main responsibilities of an Operating System?
........................................................................................................................
........................................................................................................................
........................................................................................................................
........................................................................................................................

1.5 TYPES OF OPERATING SYSTEMS

In this section we will discuss about the different types of operating systems.
Modern computer operating systems may be classied into three groups, which are
distinguished by the nature of interaction that takes place between the computer user
and his or her program during its processing. The three groups are called batch, time-
sharing and real-time operating systems.

1.5.1 Batch Processing Operating System

In a batch processing operating system environment users submit jobs to a central
place where these jobs are collected into a batch, and subsequently placed on an input

16
queue at the computer where they will be run. In this case, the user has no interaction Operating System:
An Overview
with the job during its processing, and the computer’s response time is the turnaround
time-the time from submission of the job until execution is complete, and the results are
ready for return to the person who submitted the job.

1.5.2 Time Sharing

Another mode for delivering computing services is provided by time sharing operating
systems. In this environment a computer provides computing services to several or
many users concurrently on-line. Here, the various users are sharing the central
processor, the memory, and other resources of the computer system in a manner
facilitated, controlled, and monitored by the operating system. The user, in this
environment, has nearly full interaction with the program during its execution, and the
computer’s response time may be expected to be no more than a few second.

1.5.3 Real Time Operating System (RTOS)

The third class is the real time operating systems, which are designed to service those
applications where response time is of the essence in order to prevent error,
misrepresentation or even disaster. Examples of real time operating systems are those
which handle airlines reservations, machine tool control, and monitoring of a nuclear
power station. The systems, in this case, are designed to be interrupted by external
signals that require the immediate attention of the computer system.
These real time operating systems are used to control machinery, scientific instruments
and industrial systems.An RTOS typically has very little user-interface capability, and
no end-user utilities. A very important part of an RTOS is managing the resources of
the computer so that a particular operation executes in precisely the same amount of
time every time it occurs. In a complex machine, having a part move more quickly just
because system resources are available may be just as catastrophic as having it not
move at all because the system is busy.

A number of other definitions are important to gain an understanding of operating

systems:

1.5.4 Multiprogramming Operating System

A multiprogramming operating system is a system that allows more than one active
user program (or part of user program) to be stored in main memory simultaneously.
Thus, it is evident that a time-sharing system is a multiprogramming system, but note
that a multiprogramming system is not necessarily a time-sharing system. A batch or
real time operating system could, and indeed usually does, have more than one active
user program simultaneously in main storage. Another important, and all too similar,
term is “multiprocessing”.

1.5.5 Multiprocessing System

A multiprocessing system is a computer hardware configuration that includes more
than one independent processing unit. The term multiprocessing is generally used to
refer to large computer hardware complexes found in major scientific or commercial
applications. More on multiprocessor system can be studied in Unit-1 of Block-3 of
this course. 17
Introduction to Operating 1.5.6 Networking Operating System
Systems and Process
Management
A networked computing system is a collection of physical interconnected computers.
The operating system of each of the interconnected computers must contain, in addition
to its own stand-alone functionality, provisions for handing communication and transfer
of program and data among the other computers with which it is connected.
Network operating systems are not fundamentally different from single processor
operating systems. They obviously need a network interface controller and some low-
level software to drive it, as well as programs to achieve remote login and remote files
access, but these additions do not change the essential structure of the operating systems.

1.5.7 Distributed Operating System

A distributed computing system consists of a number of computers that are connected
and managed so that they automatically share the job processing load among the
constituent computers, or separate the job load as appropriate particularly configured
processors. Such a system requires an operating system which, in addition to the typical
stand-alone functionality, provides coordination of the operations and information flow
among the component computers. The networked and distributed computing
environments and their respective operating systems are designed with more complex
functional capabilities. In a network operating system, the users are aware of the
existence of multiple computers, and can log in to remote machines and copy files from
one machine to another. Each machine runs its own local operating system and has its
own user (or users).
A distributed operating system, in contrast, is one that appears to its users as a traditional
uni-processor system, even though it is actually composed of multiple processors. In a
true distributed system, users should not be aware of where their programs are being
run or where their files are located; that should all be handled automatically and efficiently
by the operating system.
True distributed operating systems require more than just adding a little code to a uni-
processor operating system, because distributed and centralised systems differ in critical
ways. Distributed systems, for example, often allow program to run on several
processors at the same time, thus requiring more complex processor scheduling
algorithms in order to optimise the amount of parallelism achieved. More on distributed
systems can be studied in Unit-2 of Block-3 of this course.

1.5.8 Operating Systems for Embedded Devices

As embedded systems (PDAs, cellphones, point-of-sale devices, VCR’s, industrial
robot control, or even your toaster) become more complex hardware-wise with every
generation, and more features are put into them day-by-day, applications they run
require more and more to run on actual operating system code in order to keep the
development time reasonable. Some of the popular OS are:
 Nexus’s Conix - an embedded operating system for ARM processors.
 Sun’s Java OS - a standalone virtual machine not running on top of any other
OS; mainly targeted at embedded systems.
 Palm Computing’s Palm OS - Currently the leader OS for PDAs, has many
applications and supporting companies.
18
 · Microsoft’s Windows CE and Windows NT Embedded OS. Operating System:
An Overview

1.6 DESIRABLE QUALITIES OF OS

The desirable qualities of an operating system are in terms of: Usability, Facilities,
Cost, and Adaptability.
· Usability:
– Robustness
– Accept all valid inputs and can handle them.
– Consistency
– Proportionality
– Convenience
– Powerful with high level facilities.
· Facilities:
– Sufcient for intended use
– Complete
– Appropriate.
· Costs:
– Want low cost and efcient services.
– Good algorithms.
Make use of space/time tradeoffs, special hardware.
– Low overhead.
Cost of doing nothing should be low. E.g., idle time at a terminal.
– Low maintenance cost.
System should not require constant attention.
· Adaptability:
– Tailored to the environment.
Support necessary activities. Do not impose unnecessary restrictions.
What are the things people do most — make them easy.
– Changeable over time.
Adapt as needs and resources change. e.g., expanding memory and new
devices, or new user population.
– Extendible-Extensible
Adding new facilities and features - which look like the old ones.

19
Introduction to Operating
Systems and Process 1.7 OPERATING SYSTEMS: SOME EXAMPLES
Management
In the earlier section we had seen the types of operating systems. In this section we will
study some popular operating systems.

1.7.1 DOS
DOS (Disk Operating System) was the first widely-installed operating system for
personal computers. It is a master control program that is automatically run when you
start your personal computer (PC). DOS stays in the computer all the time letting you
run a program and manage files. It is a single-user operating system from Microsoft for
the PC. It was the first OS for the PC and is the underlying control program for
Windows 3.1, 95, 98 and ME. Windows NT, 2000 and XP emulate DOS in order to
support existing DOS applications.

1.7.2 UNIX
UNIX operating systems are used in widely-sold workstation products from Sun
Microsystems, Silicon Graphics, IBM, and a number of other companies. The UNIX
environment and the client/server program model were important elements in the
development of the Internet and the reshaping of computing as centered in networks
rather than in individual computers. Linux, a UNIX derivative available in both “free
software” and commercial versions, is increasing in popularity as an alternative to
proprietary operating systems.
UNIX is written in C. Both UNIX and C were developed by AT&T and freely
distributed to government and academic institutions, causing it to be ported to a wider
variety of machine families than any other operating system.As a result, UNIX became
synonymous with “open systems”.
UNIX is made up of the kernel, file system and shell (command line interface). The
major shells are the Bourne shell (original), C shell and Korn shell. The UNIX vocabulary
is exhaustive with more than 600 commands that manipulate data and text in every
way conceivable. Many commands are cryptic, but just as Windows hid the DOS
prompt, the Motif GUI presents a friendlier image to UNIX users. Even with its many
versions, UNIX is widely used in mission critical applications for client/server and
transaction processing systems. The UNIX versions that are widely used are Sun’s
Solaris, Digital’s UNIX, HP’s HP-UX, IBM’s AIX and SCO’s UnixWare. A large
number of IBM mainframes also run UNIX applications, because the UNIX interfaces
were added to MVS and OS/390, which have obtained UNIX branding. Linux, another
variant of UNIX, is also gaining enormous popularity. More details can be studied in
Unit-3 of Block-3 of this course.

1.7.3 WINDOWS
Windows is a personal computer operating system from Microsoft that, together with
some commonly used business applications such as Microsoft Word and Excel, has
become a de facto “standard” for individual users in most corporations as well as in
most homes. Windows contains built-in networking, which allows users to share files
and applications with each other if their PC’s are connected to a network. In large
enterprises, Windows clients are often connected to a network of UNIX and NetWare
servers. The server versions of Windows NT and 2000 are gaining market share,
20
providing a Windows-only solution for both the client and server. Windows is supported Operating System:
An Overview
by Microsoft, the largest software company in the world, as well as the Windows
industry at large, which includes tens of thousands of software developers.
This networking support is the reason why Windows became successful in the rst
place. However, Windows 95, 98, ME, NT, 2000 and XP are complicated operating
environments. Certain combinations of hardware and software running together can
cause problems, and troubleshooting can be daunting. Each new version of Windows
has interface changes that constantly confuse users and keep support people busy, and
Installing Windows applications is problematic too. Microsoft has worked hard to
make Windows 2000 and Windows XP more resilient to installation of problems and
crashes in general. More details on Windows 2000 can be studied in Unit-4 of Block
-3 of this course.

1.7.4 MACINTOSH
The Macintosh (often called “the Mac”), introduced in 1984 byApple Computer, was
the rst widely-sold personal computer with a graphical user interface (GUI). The
Mac was designed to provide users with a natural, intuitively understandable, and, in
general, “user-friendly” computer interface. This includes the mouse, the use of icons
or small visual images to represent objects or actions, the point-and-click and click-
and-drag actions, and a number of window operation ideas. Microsoft was successful
in adapting user interface concepts rst made popular by the Mac in its rst Windows
operating system. The primary disadvantage of the Mac is that there are fewer Mac
applications on the market than for Windows. However, all the fundamental applications
are available, and the Macintosh is a perfectly useful machine for almost everybody.
Data compatibility between Windows and Mac is an issue, although it is often overblown
and readily solved.
The Macintosh has its own operating system, Mac OS which, in its latest version is
called Mac OS X. Originally built on Motorola’s 68000 series microprocessors, Mac
versions today are powered by the PowerPC microprocessor, which was developed
jointly by Apple, Motorola, and IBM. While Mac users represent only about 5% of
the total numbers of personal computer users, Macs are highly popular and almost a
cultural necessity among graphic designers and online visual artists and the companies
they work for.
In this section we will discuss some services of the operating system used by its users.
Users of operating system can be divided into two broad classes: command language
users and system call users. Command language users are those who can interact with
operating systems using the commands. On the other hand system call users invoke
services of the operating system by means of run time system calls during the execution
of programs.
More can be read from Block-4 of MCS-203 Operating Systems.

F Check Your Progress 2

1) Discuss different views of the Operating Systems.
........................................................................................................................
........................................................................................................................

2) Summarise the characteristics of the following operating systems:

· Batch Processing 21
Introduction to Operating  Time Sharing
Systems and Process
Management  Real time
........................................................................................................................
........................................................................................................................

1.8 FUNCTIONS OF OS
The main functions of an operating system are as follows:
 Process Management
 Memory Management
 Secondary Storage Management
 I/O Management
 File Management
 Protection
 Networking Management
 Command Interpretation.

1.8.1 Process Management

The CPU executes a large number of programs. While its main concern is the execution
of user programs, the CPU is also needed for other system activities. These activities
are called processes. A process is a program in execution. Typically, a batch job is a
process. A time-shared user program is a process. A system task, such as spooling, is
also a process. For now, a process may be considered as a job or a time-shared
program, but the concept is actually more general.
The operating system is responsible for the following activities in connection with
processes management:
 The creation and deletion of both user and system processes
 The suspension and resumption of processes.
 The provision of mechanisms for process synchronization
 The provision of mechanisms for deadlock handling.
More details can be studied in the Unit-2 of this course.

1.8.2 Memory Management

Memory is the most expensive part in the computer system. Memory is a large array of
words or bytes, each with its own address. Interaction is achieved through a sequence
of reads or writes of specific memory address. The CPU fetches from and stores in
memory.
There are various algorithms that depend on the particular situation to manage the
22 memory. Selection of a memory management scheme for a specific system depends
upon many factors, but especially upon the hardware design of the system. Each algorithm Operating System:
An Overview
requires its own hardware support.
The operating system is responsible for the following activities in connection with memory
management.
 Keep track of which parts of memory are currently being used and by whom.
 Decide which processes are to be loaded into memory when memory space
becomes available.
 Allocate and deallocate memory space as needed.
Memory management techniques will be discussed in great detail in Unit-1 of Block-2
of this course.

1.8.3 Secondary Storage Management

The main purpose of a computer system is to execute programs. These programs,
together with the data they access, must be in main memory during execution. Since
the main memory is too small to permanently accommodate all data and program, the
computer system must provide secondary storage to backup main memory. Most
modem computer systems use disks as the primary on-line storage of information, of
both programs and data. Most programs, like compilers, assemblers, sort routines,
editors, formatters, and so on, are stored on the disk until loaded into memory, and
then use the disk as both the source and destination of their processing. Hence the
proper management of disk storage is of central importance to a computer system.
There are few alternatives. Magnetic tape systems are generally too slow. In addition,
they are limited to sequential access. Thus tapes are more suited for storing infrequently
used files, where speed is not a primary concern.

The operating system is responsible for the following activities in connection with disk
management:
 Free space management

 Storage allocation

 Disk scheduling.
More details can be studied in Unit-3 of Block-2 of this course.

1.8.4 I/O Management

One of the purposes of an operating system is to hide the peculiarities or specific
hardware devices from the user. For example, in UNIX, the peculiarities of I/O devices
are hidden from the bulk of the operating system itself by the I/O system. The operating
system is responsible for the following activities in connection to I/O management:
 A buffer caching system
 To activate a general device driver code
 To run the driver software for specific hardware devices as and when required.
More details can be studied in the Unit-3 of Block-2 of this course.
23
Introduction to Operating 1.8.5 File Management
Systems and Process
Management
File management is one of the most visible services of an operating system. Computers
can store information in several different physical forms: magnetic tape, disk, and drum
are the most common forms. Each of these devices has it own characteristics and
physical organisation.
For convenient use of the computer system, the operating system provides a uniform
logical view of information storage. The operating system abstracts from the physical
properties of its storage devices to define a logical storage unit, the file. Files are
mapped, by the operating system, onto physical devices.

A file is a collection of related information defined by its creator. Commonly, files

represent programs (both source and object forms) and data. Data files may be numeric,
alphabetic or alphanumeric. Files may be free-form, such as text files, or may be rigidly
formatted. In general a files is a sequence of bits, bytes, lines or records whose meaning
is defined by its creator and user. It is a very general concept.

The operating system implements the abstract concept of the file by managing mass
storage device, such as types and disks.Also files are normally organised into directories
to ease their use. Finally, when multiple users have access to files, it may be desirable
to control by whom and in what ways files may be accessed.

The operating system is responsible for the following activities in connection to the file
management:
 The creation and deletion of files.

 The creation and deletion of directory.

 The support of primitives for manipulating files and directories.

 The mapping of files onto disk storage.

 Backup of files on stable (non volatile) storage.

 Protection and security of the files.

1.8.6 Protection
The various processes in an operating system must be protected from each other’s
activities. For that purpose, various mechanisms which can be used to ensure that the
files, memory segment, CPU and other resources can be operated on only by those
processes that have gained proper authorisation from the operating system.
For example, memory addressing hardware ensures that a process can only execute
within its own address space. The timer ensures that no process can gain control of the
CPU without relinquishing it. Finally, no process is allowed to do its own I/O, to
protect the integrity of the various peripheral devices. Protection refers to a mechanism
for controlling the access of programs, processes, or users to the resources defined by
a computer controls to be imposed, together with some means of enforcement.
Protection can improve reliability by detecting latent errors at the interfaces between
component subsystems. Early detection of interface errors can often prevent
contamination of a healthy subsystem by a subsystem that is malfunctioning. An
24
unprotected resource cannot defend against use (or misuse) by an unauthorised or Operating System:
An Overview
incompetent user. More on protection and security can be studied in Unit-4 of
Block-3.

1.8.7 Networking
A distributed system is a collection of processors that do not share memory or a clock.
Instead, each processor has its own local memory, and the processors communicate
with each other through various communication lines, such as high speed buses or
telephone lines. Distributed systems vary in size and function. They may involve
microprocessors, workstations, minicomputers, and large general purpose computer
systems.
The processors in the system are connected through a communication network, which
can be configured in the number of different ways. The network may be fully or partially
connected. The communication network design must consider routing and connection
strategies and the problems of connection and security.
A distributed system provides the user with access to the various resources the system
maintains.Access to a shared resource allows computation speed-up, data availability,
and reliability.

1.8.8 Command Interpretation

One of the most important components of an operating system is its command
interpreter. The command interpreter is the primary interface between the user and the
rest of the system.
Many commands are given to the operating system by control statements. When a
new job is started in a batch system or when a user logs-in to a time-shared system, a
program which reads and interprets control statements is automatically executed. This
program is variously called (1) the control card interpreter, (2) the command line
interpreter, (3) the shell (in Unix), and so on. Its function is quite simple: get the next
command statement, and execute it.
The command statements themselves deal with process management, I/O handling,
secondary storage management, main memory management, file system access,
protection, and networking.
The Figure 2 depicts the role of the operating system in coordinating all the functions.

Figure 2: Functions Coordinated by the Operating System 25

Introduction to Operating
Systems and Process

Check Your Progress 3
Management
1) Mention the advantages and limitations of Multiuser Operating Systems
........................................................................................................................
........................................................................................................................
........................................................................................................................

2) What is a Multitasking system and mention its advantages.

........................................................................................................................
........................................................................................................................
........................................................................................................................

3) Illustrate a simple operating system for a security control system.

........................................................................................................................
........................................................................................................................
........................................................................................................................

1.9 SUMMARY
This Unit presented the principle operation of an operating system. In this unit we had
briefly described about the history, the generations and the types of operating systems.
An operating system is a program that acts as an interface between a user of a computer
and the computer hardware. The purpose of an operating system is to provide an
environment in which a user may execute programs. The primary goal of an operating
system is to make the computer convenient to use. And the secondary goal is to use
the hardware in an efficient manner.
Operating systems may be classified by both how many tasks they can perform
“simultaneously” and by how many users can be using the system “simultaneously”.
That is: single-user or multi-user and single-task or multi-tasking. A multi-user
system must clearly be multi-tasking. In the next unit we will discuss the concept of
processes and their management by the OS.

1.10 SOLUTIONS/ANSWERS
Check Your Progress 1
1) The most important type of system software is the operating system.An operating
system has three main responsibilities:
 Perform basic tasks, such as recognising input from the keyboard, sending
output to the display screen, keeping track of files and directories on the disk,
and controlling peripheral devices such as disk drives and printers.
 Ensure that different programs and users running at the same time do not
interfere with each other.
26
  Provide a software platform on top of which other programs (i.e., application Operating System:
An Overview
software) can run.
The first two responsibilities address the need for managing the computer hardware
and the application programs that use the hardware. The third responsibility focuses
on providing an interface between application software and hardware so that application
software can be efficiently developed. Since the operating system is already responsible
for managing the hardware, it should provide a programming interface for application
developers.
Check Your Progress 2
1) The following are the different views of the operating system.
As a scheduler/allocator:
 The operating system has resources for which it is in charge.
 Responsible for handing them out (and later recovering them).
 Resources include CPU, memory, I/O devices, and disk space.
As a virtual machine:
 Operating system provides a “new” machine.
– This machine could be the same as the underlying machine.Allows many
users to believe they have an entire piece of hardware to themselves.
– This could implement a different, perhaps more powerful, machine. Or
just a different machine entirely. It may be useful to be able to completely
simulate another machine with your current hardware.
As a multiplexer:
 Allows sharing of resources, and provides protection from interference.
 Provides for a level of cooperation between users.
 Economic reasons: we have to take turns.
2) Batch Processing: This strategy involves reading a series of jobs (called a batch)
into the machine and then executing the programs for each job in the batch. This
approach does not allow users to interact with programs while they operate.
Time Sharing: This strategy supports multiple interactive users. Rather than
preparing a job for execution ahead of time, users establish an interactive session
with the computer and then provide commands, programs and data as they are
needed during the session.
Real Time: This strategy supports real-time and process control systems. These
are the types of systems which control satellites, robots, and air-traffic control.
The dedicated strategy must guarantee certain response times for particular
computing tasks or the application is useless.
Check Your Progress 3
1) The advantage of having a multi-user operating system is that normally the hardware
is very expensive, and it lets a number of users share this expensive resource. This 27
Introduction to Operating means the cost is divided amongst the users. It also makes better use of the
Systems and Process
Management resources. Since the resources are shared, they are more likely to be in use than
sitting idle being unproductive.
One limitation with multi-user computer systems is that as more users access it,
the performance becomes slower and slower. Another limitation is the cost of
hardware, as a multi-user operating system requires a lot of disk space and memory.
In addition, the actual software for multi-user operating systems tend to cost more
than single-user operating systems.
2) A multi-tasking operating system provides the ability to run more than one program
at once. For example, a user could be running a word processing package, printing
a document, copying files to the floppy disk and backing up selected files to a tape
unit. Each of these tasks the user is doing appears to be running at the same time.
A multi-tasking operating system has the advantage of letting the user run more
than one task at once, so this leads to increased productivity. The disadvantage is
that more programs that are run by the user, the more memory is required.
3) An operating system for a security control system (such as a home alarm system)
would consist of a number of programs. One of these programs would gain control
of the computer system when it is powered on, and initialise the system. The first
task of this initialise program would be to reset (and probably test) the hardware
sensors and alarms. Once the hardware initialisation was complete, the operating
system would enter a continual monitoring routine of all the input sensors. If the
state of any input sensor is changed, it would branch to an alarm generation routine.

1.11 FURTHER READINGS

1) Madnick and Donovan, Operating systems – Concepts and design, McGrawHill
Intl. Education.
2) Milan Milenkovic, Operating Systems, Concepts and Design, TMGH, 2000.
3) D.M. Dhamdhere, Operating Systems, A concept-based approach, TMGH,
2002.
4) Abraham Silberschatz and James L, Operating System Concepts.
Peterson,Addition Wesley Publishing Company.
5) Harvay M. Deital, Introduction to Operating Systems, Addition Wesley
Publishing Company.
6) Andrew S. Tanenbaum, Operating System Design and Implementation, PHI.

28
 Operating System:
UNIT 2 PROCESSES An Overview

Structure

2.1 Introduction
2.2 Objectives
2.3 The Concept of Process
2.3.1 Implicit and Explicit Tasking
2.3.2 Processes Relationship
2.3.3 Process States
2.3.4 Implementation of Processes
2.3.5 Process Hierarchy
2.3.6 Threads
2.3.7 Levels of Threads
2.4 System Calls for Process Management
2.5 Process Scheduling
2.5.1 Scheduling Objectives
2.5.2 Types of Schedulers
2.5.3 Scheduling Criteria
2.6 Scheduling Algorithms
2.6.1 First Come First Serve (FCFS)
2.6.2 Shortest Job First (SJF)
2.6.3 Round Robin (RR)
2.6.4 Shortest Remaining Time Next (SRTN)
2.6.5 Priority Based Scheduling or Event Driven (ED) Scheduling
2.7 Performance Evaluation of the Scheduling Algorithms
2.8 Summary
2.9 Solutions/Answers
2.10 Further Readings

2.1 INTRODUCTION
In the earlier unit we have studied the overview and the functions of an operating
system. In this unit we will have detailed discussion on the processes and their
management by the operating system. The other resource management features of
operating systems will be discussed in the subsequent units.
The CPU executes a large number of programs. While its main concern is the execution
of user programs, the CPU is also needed for other system activities. These activities
are called processes. A process is a program in execution. Typically, a batch job is a
process. A time-shared user program is a process. A system task, such as spooling, is
also a process. For now, a process may be considered as a job or a time-shared
program, but the concept is actually more general.
In general, a process will need certain resources such as CPU time, memory, files, I/O
devices, etc., to accomplish its task. These resources are given to the process when it 29
Introduction to Operating is created. In addition to the various physical and logical resources that a process
Systems and Process
Management obtains when it is created, some initialisation data (input) may be passed along. For
example, a process whose function is to display the status of a file, say F1, on the
screen, will get the name of the file F1 as an input and execute the appropriate program
to obtain the desired information.
We emphasize that a program by itself is not a process; a program is a passive entity,
while a process is an active entity. It is known that two processes may be associated
with the same program; they are nevertheless considered two separate execution
sequences.
A process is the unit of work in a system. Such a system consists of a collection of
processes, some of which are operating system processes, those that execute system
code, and the rest being user processes, those that execute user code. All of those
processes can potentially execute concurrently.
The operating system is responsible for the following activities in connection with
processes managed.
 The creation and deletion of both user and system processes;
 The suspension is resumption of processes;
 The provision of mechanisms for process synchronization, and
 The provision of mechanisms for deadlock handling.
We will learn the operating system view of the processes, types of schedulers, different
types of scheduling algorithms, in the subsequent sections of this unit.

2.2 OBJECTIVES
After going through this unit, you should be able to:
 understand the concepts of process, various states in the process and their
scheduling;
 define a process control block;
 classify different types of schedulers;
 understand various types of scheduling algorithms, and
 compare the performance evaluation of the scheduling algorithms.

2.3 THE CONCEPT OF PROCESS

The term “process” was first used by the operating system designers of the MULTICS
system way back in 1960s. There are different definitions to explain the concept of
process. Some of these are, a process is:
 An instance of a program in execution
 An asynchronous activity
 The “animated spirit” of a procedure
30
  The “locus of control” of a procedure in execution Processes

 The “dispatchable” unit

 Unit of work individually schedulable by an operating system.
Formally, we can define a process is an executing program, including the current
values of the program counter, registers, and variables. The subtle difference between
a process and a program is that the program is a group of instructions whereas the
process is the activity.
In multiprogramming systems, processes are performed in a pseudo-parallelism as if
each process has its own processor. In fact, there is only one processor but it switches
back and forth from process to process. Henceforth, by saying execution of a process,
we mean the processor’s operations on the process like changing its variables, etc.
and I/O work means the interaction of the process with the I/O operations like reading
something or writing to somewhere. They may also be named as “processor (CPU)
burst” and “I/O burst” respectively. According to these definitions, we classify
programs as:
 Processor- bound program: A program having long processor bursts
(execution instants)
 I/O- bound program: Aprogram having short processor bursts.
The operating system works as the computer system software that assists hardware in
performing process management functions. Operating system keeps track of all the
active processes and allocates system resources to them according to policies devised
to meet design performance objectives. To meet process requirements OS must
maintain many data structures efficiently. The process abstraction is fundamental
means for the OS to manage concurrent program execution. OS must interleave the
execution of a number of processes to maximize processor use while providing
reasonable response time. It must allocate resources to processes in conformance
with a specific policy. In general, a process will need certain resources such as CPU
time, memory, files, I/O devices etc. to accomplish its tasks. These resources are
allocated to the process when it is created. A single processor may be shared among
several processes with some scheduling algorithm being used to determine when to
stop work on one process and provide service to a different one which we will discuss
later in this unit.
Operating systems must provide some way to create all the processes needed. In
simple systems, it may be possible to have all the processes that will ever be needed be
present when the system comes up. In almost all systems however, some way is needed
to create and destroy processes as needed during operations. In UNIX, for instant,
processes are created by the fork system call, which makes an identical copy of the
calling process. In other systems, system calls exist to create a process, load its memory,
and start it running. In general, processes need a way to create other processes. Each
process has one parent process, but zero, one, two, or more children processes.
For an OS, the process management functions include:
 Process creation
 Termination of the process
31
Introduction to Operating  Controlling the progress of the process
Systems and Process
Management  Process Scheduling
 Dispatching
 Interrupt handling / Exceptional handling
 Switching between the processes
 Process synchronization
 Interprocess communication support
 Management of Process Control Blocks.

2.2.1 Implicit and Explicit Tasking

A separate process at run time can be either–

 Implicit tasking and

 Explicit tasking.
Implicit tasking means that processes are defined by the system. It is commonly
encountered in general purpose multiprogramming systems. In this approach, each
program submitted for execution is treated by the operating system as an independent
process. Processes created in this manner are usually transient in the sense that they
are destroyed and disposed of by the system after each run.
Explicit tasking means that programs explicitly define each process and some of its
attributes. To improve the performance, a single logical application is divided into various
related processes. Explicit tasking is used in situations where high performance in desired
system programs such as parts of the operating system and real time applications are
common examples of programs defined processes.After dividing process into several
independent processes, a system programs defines the confines of each individual
process. A parent process is then commonly added to create the environment for and
to control execution of individual processes.
Common reasons for and uses of explicit tasking include:

 Speedup: Explicit tasking can result in faster execution of applications.

 Driving I/O devices that have latency: While one task is waiting for I/O
to complete, another portion of the application can make progress towards
completion if it contains other tasks that can do useful work in the interim.
 User convenience: By creating tasks to handle individual actions, a graphical
interface can allow users to launch several operations concurrently by clicking
on action icons before completion of previous commands.

 Multiprocessing and multicomputing: Aprogram coded as a collection of

tasks can be relatively easily posted to a multiprocessor system, where
individual tasks may be executed on different processors in parallel.

Distributed computing network server can handle multiple concurrent client sessions
by dedicating an individual task to each active client session.
32
2.2.2 Processes Relationship Processes

In the concurrent environment basically processes have two relationships, competition

and cooperation. In the concurrent environment, processes compete with each other
for allocation of system resources to execute their instructions. In addition, a collection
of related processes that collectively represent a single logical application cooperate
with each other. There should be a proper operating system to support these relations.
In the competition, there should be proper resource allocation and protection in address
generation.
We distinguish between independent process and cooperating process. A process is
independent if it cannot affect or be affected by other processes executing in the system.
Independent process: These type of processes have following features:
 Their state is not shared in any way by any other process.
 Their execution is deterministic, i.e., the results of execution depend only on
the input values.
 Their execution is reproducible, i.e., the results of execution will always be
the same for the same input.
 Their execution can be stopped and restarted without any negative effect.
Cooperating process: In contrast to independent processes, cooperating processes
can affect or be affected by other processes executing the system. They are characterised
by:
 Their states are shared by other processes.
 Their execution is not deterministic, i.e., the results of execution depend on
relative execution sequence and cannot be predicted in advance.
Their execution is irreproducible, i.e., the results of execution are not always the same
for the same input.

2.2.3 Process States

As defined, a process is an independent entity with its own input values, output values,
and internal state. A process often needs to interact with other processes. One process
may generate some outputs that other process uses as input. For example, in the shell
command
cat file1 file2 file3 | grep tree
The first process, running cat, concatenates and outputs three files. Depending on the
relative speed of the two processes, it may happen that grep is ready to run, but there
is no input waiting for it. It must then block until some input is available. It is also
possible for a process that is ready and able to run to be blocked because the operating
system is decided to allocate the CPU to other process for a while.
A process state may be in one of the following:
 New : The process is being created.
 Ready : The process is waiting to be assigned to a processor.
33
Introduction to Operating  Running : Instructions are being executed.
Systems and Process
Management
 Waiting/Suspended/Blocked : The process is waiting for some event to
occur.
 Halted/Terminated : The process has finished execution.
The transition of the process states are shown in Figure 1.and their corresponding
transition are described below:

Figure 1: Typical process states

As shown in Figure 1, four transitions are possible among the states.

Transition 1 appears when a process discovers that it cannot continue. In order to get
into blocked state, some systems must execute a system call block. In other systems,
when a process reads from a pipe or special file and there is no input available, the
process is automatically blocked.

Transition 2 and 3 are caused by the process scheduler, a part of the operating system.
Transition 2 occurs when the scheduler decides that the running process has run long
enough, and it is time to let another process have some CPU time. Transition 3 occurs
when all other processes have had their share and it is time for the first process to run
again.

Transition 4 appears when the external event for which a process was waiting was
happened. If no other process is running at that instant, transition 3 will be triggered
immediately, and the process will start running. Otherwise it may have to wait in ready
state for a little while until the CPU is available.

Using the process model, it becomes easier to think about what is going on inside the
system. There are many processes like user processes, disk processes, terminal
processes, and so on, which may be blocked when they are waiting for something to
happen. When the disk block has been read or the character typed, the process waiting
for it is unblocked and is ready to run again.

The process model, an integral part of an operating system, can be summarized as

follows. The lowest level of the operating system is the scheduler with a number of
processes on top of it.All the process handling, such as starting and stopping processes
are done by the scheduler. More on the schedulers can be studied is the subsequent
34 sections.
2.2.4 Implementation of Processes Processes

To implement the process model, the operating system maintains a table, an array of
structures, called the process table or process control block (PCB) or Switch frame.
Each entry identifies a process with information such as process state, its program
counter, stack pointer, memory allocation, the status of its open files, its accounting
and scheduling information. In other words, it must contain everything about the process
that must be saved when the process is switched from the running state to the ready
state so that it can be restarted later as if it had never been stopped. The following is
the information stored in a PCB.
 Process state, which may be new, ready, running, waiting or halted;
 Process number, each process is identified by its process number, called process
ID;
 Program counter, which indicates the address of the next instruction to be executed
for this process;
 CPU registers, which vary in number and type, depending on the concrete
microprocessor architecture;
 Memory management information, which include base and bounds registers or
page table;
 I/O status information, composed I/O requests, I/O devices allocated to this process,
a list of open files and so on;
 Processor scheduling information, which includes process priority, pointers to
scheduling queues and any other scheduling parameters;
 List of open files.
A process structure block is shown in Figure 2.

Figure 2: Process Control Block Structure

Context Switch
A context switch (also sometimes referred to as a process switch or a task switch)
is the switching of the CPU (central processing unit) from one process or to another. 35
Introduction to Operating A context is the contents of a CPU’s registers and program counter at any point in
Systems and Process
Management time.
A context switch is sometimes described as the kernel suspending execution of one
process on the CPU and resuming execution of some other process that had previously
been suspended.
Context Switch: Steps
In a context switch, the state of the first process must be saved somehow, so that,
when the scheduler gets back to the execution of the first process, it can restore this
state and continue normally.
The state of the process includes all the registers that the process may be using, especially
the program counter, plus any other operating system specific data that may be necessary.
Often, all the data that is necessary for state is stored in one data structure, called a
process control block (PCB). Now, in order to switch processes, the PCB for the first
process must be created and saved. The PCBs are sometimes stored upon a per-
process stack in the kernel memory, or there may be some specific operating system
defined data structure for this information.
Let us understand with the help of an example. Suppose if two processes A and B are
in ready queue. If CPU is executing Process A and Process B is in wait state. If an
interrupt occurs for ProcessA, the operating system suspends the execution of the first
process, and stores the current information of Process A in its PCB and context to the
second process namely Process B. In doing so, the program counter from the PCB of
Process B is loaded, and thus execution can continue with the new process. The
switching between two processes, ProcessAand Process B is illustrated in the Figure
3 given below:

Figure 3: Process switching between two processes

2.2.5 Process Hierarchy

Modern general purpose operating systems permit a user to create and destroy
36 processes. A process may create several new processes during its time of execution.
The creating process is called parent process, while the new processes are called child Processes
processes. There are different possibilities concerning creating new processes:
 Execution: The parent process continues to execute concurrently with its
children processes or it waits until all of its children processes have terminated
(sequential).
 Sharing: Either the parent and children processes share all resources (likes
memory or files) or the children processes share only a subset of their parent’s
resources or the parent and children processes share no resources in common.
A parent process can terminate the execution of one of its children for one of these
reasons:
 The child process has exceeded its usage of the resources it has been allocated.
In order to do this, a mechanism must be available to allow the parent process
to inspect the state of its children processes.
 The task assigned to the child process is no longer required.
Let us discuss this concept with an example. In UNIX this is done by the fork system
call, which creates a child process, and the exit system call, which terminates the
current process.After a fork both parent and child keep running (indeed they have the
same program text) and each can fork off other processes. This results in a process
tree. The root of the tree is a special process created by the OS during startup. A
process can choose to wait for children to terminate. For example, if C issued a wait( )
system call it would block until G finished. This is shown in the Figure 4.

Figure 4: Process hierarchy

Old or primitive operating system like MS-DOS are not multiprogrammed so when
one process starts another, the first process is automatically blocked and waits until
the second is finished.

2.2.6 Threads
Threads, sometimes called lightweight processes (LWPs) are independently scheduled
parts of a single program. We say that a task is multithreaded if it is composed of
several independent sub-processes which do work on common data, and if each of
those pieces could (at least in principle) run in parallel.
If we write a program which uses threads – there is only one program, one executable
file, one task in the normal sense. Threads simply enable us to split up that program 37
Introduction to Operating into logically separate pieces, and have the pieces run independently of one another,
Systems and Process
Management until they need to communicate. In a sense, threads are a further level of object
orientation for multitasking systems. They allow certain functions to be executed in
parallel with others.
On a truly parallel computer (several CPUs) we might imagine parts of a program
(different subroutines) running on quite different processors, until they need to
communicate. When one part of the program needs to send data to the other part, the
two independent pieces must be synchronized, or be made to wait for one another.
But what is the point of this? We can always run independent procedures in a program
as separate programs, using the process mechanisms we have already introduced.
They could communicate using normal interprocesses communication. Why introduce
another new concept? Why do we need threads?
The point is that threads are cheaper than normal processes, and that they can be
scheduled for execution in a user-dependent way, with less overhead. Threads are
cheaper than a whole process because they do not have a full set of resources each.
Whereas the process control block for a heavyweight process is large and costly to
context switch, the PCBs for threads are much smaller, since each thread has only a
stack and some registers to manage. It has no open file lists or resource lists, no
accounting structures to update.All of these resources are shared by all threads within
the process. Threads can be assigned priorities – a higher priority thread will get put to
the front of the queue. Let’s define heavy and lightweight processes with the help of a
table.

Why use threads?

The sharing of resources can be made more effective if the scheduler knows known
exactly what each program was going to do in advance. Of course, the scheduling
algorithm can never know this – but the programmer who wrote the program does
know. Using threads it is possible to organise the execution of a program in such a way
that something is always being done, whenever the scheduler gives the heavyweight
process CPU time.
 Threads allow a programmer to switch between lightweight processes when
it is best for the program. (The programmer has control).
 A process which uses threads does not get more CPU time than an ordinary
process – but the CPU time it gets is used to do work on the threads. It is
possible to write a more efficient program by making use of threads.
 Inside a heavyweight process, threads are scheduled on a FCFS basis, unless
the program decides to force certain threads to wait for other threads. If there
is only one CPU, then only one thread can be running at a time.
 Threads context switch without any need to involve the kernel-the switching
is performed by a user level library, so time is saved because the kernel doesn’t
38 need to know about the threads.
2.2.7 Levels of Threads Processes

In modern operating systems, there are two levels at which threads operate: system or
kernel threads and user level threads. If the kernel itself is multithreaded, the scheduler
assigns CPU time on a thread basis rather than on a process basis. A kernel level
thread behaves like a virtual CPU, or a power-point to which user-processes can
connect in order to get computing power. The kernel has as many system level threads
as it has CPUs and each of these must be shared between all of the user-threads on the
system. In other words, the maximum number of user level threads which can be active
at any one time is equal to the number of system level threads, which in turn is equal to
the number of CPUs on the system.
Since threads work “inside” a single task, the normal process scheduler cannot normally
tell which thread to run and which not to run – that is up to the program. When the
kernel schedules a process for execution, it must then find out from that process which
is the next thread it must execute. If the program is lucky enough to have more than one
processor available, then several threads can be scheduled at the same time.
Some important implementations of threads are:
 The Mach System / OSF1 (user and system level)
 Solaris 1 (user level)
 Solaris 2 (user and system level)
 OS/2 (system level only)
 NT threads (user and system level)
 IRIX threads
 POSIX standardized user threads interface.


Check Your Progress 1
1) Explain the difference between a process and a thread with some examples.
........................................................................................................................
........................................................................................................................
........................................................................................................................

2) Identify the different states a live process may occupy and show how a process
moves between these states.
........................................................................................................................
........................................................................................................................
........................................................................................................................

3) Define what is meant by a context switch. Explain the reason many systems use
two levels of scheduling.
........................................................................................................................
........................................................................................................................
........................................................................................................................ 39
Introduction to Operating
Systems and Process 2.3 SYSTEM CALLS FOR PROCESS
Management
MANAGEMENT
In this section we will discuss system calls typically provided by the kernels of
multiprogramming operating systems for process management. System calls provide
the interface between a process and the operating system. These system calls are the
routine services of the operating system.As an example of how system calls are used,
consider writing a simple program to read data from one file and to copy them to
another file. There are two names of two different files in which one input file and the
other is the output file. One approach is for the program to ask the user for the names
of the two files. In an interactive system, this approach will require a sequence of
system calls, first to write a prompting message on the screen and then to read from the
keyboard the character that the two files have. Once the two file names are obtained
the program must open the input file and create the output file. Each of these operations
requires another system call and may encounter possible error conditions. When the
program tries to open the input file, it may find that no file of that name exists or that the
file is protected against access. In these cases the program should print the message on
the console and then terminate abnormally which require another system call. If the
input file exists then we must create the new output file. We may find an output file with
the same name. This situation may cause the program to abort or we may delete the
existing file and create a new one. After opening both files, we may enter a loop that
reads from input file and writes to output file. Each read and write must return status
information regarding various possible error conditions. Finally, after the entire file is
copied the program may close both files. Examples of some operating system calls are:
Create: In response to the create call the operating system creates a new process
with the specified or default attributes and identifier. Some of the parameters definable
at the process creation time include:
 level of privilege, such as system or user
 priority
 size and memory requirements
 maximum data area and/or stack size
 memory protection information and access rights
 other system dependent data.
Delete: The delete service is also called destroy, terminate or exit. Its execution causes
the operating system to destroy the designated process and remove it from the system.
Abort: It is used to terminate the process forcibly.Although a process could conceivably
abort itself, the most frequent use of this call is for involuntary terminations, such as
removal of malfunctioning process from the system.
Fork/Join:Another method of process creation and termination is by means of FORK/
JOIN pair, originally introduced as primitives for multiprocessor system. The FORK
operations are used to split a sequence of instruction into two concurrently executable
sequences. JOIN is used to merge the two sequences of code divided by the FORK
40 and it is available to a parent process for synchronization with a child.
Suspend: The suspend system call is also called BLOCK in some systems. The Processes
designated process is suspended indenitely and placed in the suspend state. A
process may be suspended itself or another process when authorized to do so.
Resume: The resume system call is also called WAKEUP in some systems. This call
resumes the target process, which is presumably suspended. Obviously a suspended
process can not resume itself because a process must be running to have its operating
system call processed. So a suspended process depends on a partner process to issue
the resume.
Delay: The system call delay is also known as SLEEP. The target process is suspended
for the duration of the specied time period. The time may be expressed in terms of
system clock ticks that are system dependent and not portable or in standard time
units such as seconds and minutes. A process may delay itself or optionally, delay
some other process.
Get_Attributes: It is an enquiry to which the operating system responds by providing
the current values of the process attributes, or their specied subset, from the PCB.
Change Priority: It is an instance of a more general SET-PROCESS-ATTRIBUTES
system call. Obviously, this call is not implemented in systems where process priority is
static.

2.4 PROCESS SCHEDULING

Scheduling is a fundamental operating system function. All computer resources are
scheduled before use. Since CPU is one of the primary computer resources, its
scheduling is central to operating system design. Scheduling refers to a set of policies
and mechanisms supported by operating system that controls the order in which the
work to be done is completed. A scheduler is an operating system program (module)
that selects the next job to be admitted for execution. The main objective of scheduling
is to increase CPU utilisation and higher throughput. Throughput is the amount of
work accomplished in a given time interval. CPU scheduling is the basis of operating
system which supports multiprogramming concepts. By having a number of programs
in computer memory at the same time, the CPU may be shared among them. This
mechanism improves the overall efciency of the computer system by getting more
work done in less time. In this section we will describe the scheduling objectives, the
three types of schedulers and performance criteria that schedulers may use in maximizing
system performance. Finally at the end of the unit, we will study various scheduling
algorithms.

2.4.1 Scheduling Objectives

The primary objective of scheduling is to improve system performance. Various
objectives of the scheduling are as follows:
· Maximize throughput: Scheduling should attempt to service the largest
possible number of processes per unit time.
· Maximize the number of interactive user receiving acceptable response times.
· Be predictable: A given job should utilize the same amount of time and
should cost the same regardless of the load on the system.
41
Introduction to Operating  Minimize overhead: Scheduling should minimize the wasted resources
Systems and Process
Management overhead.
 Balance resource use: The scheduling mechanisms should keep the
resources of the system busy. Processes that will use under utilized resources
should be favoured.
 Achieve a balance between response and utilisation: The best way to
guarantee good response times is to have sufficient resources available
whenever they are needed. In real time system fast responses are essential,
and resource utilisation is less important.
 Avoid indefinite postponement : It would be fair if all processes are treated
the same, and no process can suffer indefinite postponement.
 Enforce Priorities: In environments in which processes are given priorities,
the scheduling mechanism should favour the higher-priority processes.
 Give preference to processes holding key resources: Even though a
low priority process may be holding a key resource, the process may be in
demand by high priority processes. If the resource is not perceptible, then the
scheduling mechanism should give the process better treatment that it would
ordinarily receive so that the process will release the key resource sooner.
 Degrade gracefully under heavy loads: A scheduling mechanism should
not collapse under heavy system load. Either it should prevent excessive
loading by not allowing new processes to be created when the load in heavy
or it should provide service to the heavier load by providing a moderately
reduced level of service to all processes.

2.4.2 Types of Schedulers

If we consider batch systems, there will often be more processes submitted than the
number of processes that can be executed immediately. So, the incoming processes
are spooled onto a disk. There are three types of schedulers. They are:
 Short term scheduler
 Long term scheduler
 Medium term scheduler
Short term scheduler: The short-term scheduler selects the process for the processor
among the processes which are already in queue (in memory). The scheduler will
execute quite frequently (mostly at least once every 10 milliseconds). It has to be very
fast in order to achieve a better processor utilization. The short term scheduler, like all
other OS programs, has to execute on the processor. If it takes 1 millisecond to choose
a process that means ( 1 / ( 10 + 1 )) = 9% of the processor time is being used for short
time scheduling and only 91% may be used by processes for execution.
Long term scheduler: The long-term scheduler selects processes from the process
pool and loads selected processes into memory for execution. The long-term scheduler
executes much less frequently when compared with the short term scheduler. It controls
the degree of multiprogramming (no. of processes in memory at a time). If the degree
of multiprogramming is to be kept stable (say 10 processes at a time), the long-term
42
Scheduler may only need to be invoked till the process finishes execution. The long- Processes
term scheduler must select a good process mix of I/O-bound and processor bound
processes. If most of the processes selected are I/O-bound, then the ready queue will
almost be empty, while the device queue(s) will be very crowded. If most of the
processes are processor-bound, then the device queue(s) will almost be empty while
the ready queue is very crowded and that will cause the short-term scheduler to be
invoked very frequently. Time-sharing systems (mostly) have no long-term scheduler.
The stability of these systems either depends upon a physical limitation (no. of available
terminals) or the self-adjusting nature of users (if you can’t get response, you quit). It
can sometimes be good to reduce the degree of multiprogramming by removing
processes from memory and storing them on disk. These processes can then be
reintroduced into memory by the medium-term scheduler. This operation is also
known as swapping. Swapping may be necessary to improve the process mix or to
free memory.

2.4.3 Scheduling Criteria

The goal of scheduling algorithm is to identify the process whose selection will result in
the “best” possible system performance. There are different scheduling algorithms,
which has different properties and may favour one class of processes over another,
which algorithm is best, to determine this there are different characteristics used for
comparison. The scheduling algorithms which we will discuss in the next section,
determines the importance of each of the criteria.
In order to achieve an efficient processor management, OS tries to select the most
appropriate process from the ready queue. For selecting, the relative importance of
the following may be considered as performance criteria:
CPU Utilization: The key idea is that if the CPU is busy all the time, the utilization
factor of all the components of the system will be also high. CPU utilization is the ratio
of busy time of the processor to the total time passes for processes to finish.
Processor Utilization = (Processor busy time) / (Processor busy time + Processor
idle time)
Throughput: It refers to the amount of work completed in a unit of time. One way to
measure throughput is by means of the number of processes that are completed in a
unit of time. The higher the number of processes, the more work apparently is being
done by the system. But this approach is not very useful for comparison because this is
dependent on the characteristics and resource requirement of the process being
executed. Therefore to compare throughput of several scheduling algorithms it should
be fed into the process with similar requirements. The throughput can be calculated by
using the formula:
Throughput = (No. of processes completed) / (Time unit)
Turnaround Time : It may be defined as interval from the time of submission of a
process to the time of its completion. It is the sum of the periods spent waiting to get
into memory, waiting in the ready queue, CPU time and I/O operations.
Turnaround Time = t(Process completed) – t(Process submitted)
Waiting Time: This is the time spent in the ready queue. In multiprogramming operating
system several jobs reside at a time in memory. CPU executes only one job at a time.
43
Introduction to Operating The rest of jobs wait for the CPU. The waiting time may be expressed as turnaround
Systems and Process
Management time, less than the actual processing time.
Waiting time = Turnaround Time - Processing Time
But the scheduling algorithm affects or considers the amount of time that a process
spends waiting in a ready queue. Thus rather than looking at turnaround time waiting
time is usually the waiting time for each process.
Response time: It is most frequently considered in time sharing and real time operating
system. However, its characteristics differ in the two systems. In time sharing system
it may be defined as interval from the time the last character of a command line of a
program or transaction is entered to the time the last result appears on the terminal.
In real time system it may be defined as interval from the time an internal or external
event is signalled to the time the first instruction of the respective service routine is
executed.
Response time = t(first response) – t(submission of request)
One of the problems in designing schedulers and selecting a set of its performance
criteria is that they often conflict with each other. For example, the fastest response
time in time sharing and real time system may result in low CPU utilization.
Throughput and CPU utilization may be increased by executing the large number of
processes, but then response time may suffer. Therefore, the design of a scheduler
usually requires balance of all the different requirements and constraints. In the next
section we will discuss various scheduling algorithms.


Check Your Progress 2
1) Distinguish between a foreground and a background process in UNIX.
........................................................................................................................
........................................................................................................................
........................................................................................................................

2) Identify the information which must be maintained by the operating system for
each live process.
........................................................................................................................
........................................................................................................................
........................................................................................................................

2.5 SCHEDULING ALGORITHMS

Now let’s discuss some processor scheduling algorithms again stating that the goal is
to select the most appropriate process in the ready queue.
CPU scheduling deals with the problem of deciding which of the processes in the
ready queue is to be allocated to the CPU. There are several scheduling algorithms
which will be examined in this section. A major division among scheduling algorithms is
44 that whether they support pre-emptive or non-preemptive scheduling discipline.
Preemptive scheduling: Preemption means the operating system moves a process Processes

from running to ready without the process requesting it. An OS implementing this
algorithms switches to the processing of a new request before completing the processing
of the current request. The preempted request is put back into the list of the pending
requests. Its servicing would be resumed sometime in the future when it is scheduled
again. Preemptive scheduling is more useful in high priority process which requires
immediate response. For example, in Real time system the consequence of missing
one interrupt could be dangerous.

Round Robin scheduling, priority based scheduling or event driven scheduling and
SRTN are considered to be the preemptive scheduling algorithms.

Non–Preemptive scheduling: A scheduling discipline is non-preemptive if once a

process has been allotted to the CPU, the CPU cannot be taken away from the process.
A non-preemptible discipline always processes a scheduled request to its completion.
In non-preemptive systems, jobs are made to wait by longer jobs, but the treatment of
all processes is fairer.

First come First Served (FCFS) and Shortest Job First (SJF), are considered to be
the non-preemptive scheduling algorithms.

The decision whether to schedule preemptive or not depends on the environment and
the type of application most likely to be supported by a given operating system.

2.5.1 First-Come First-Serve (FCFS)

The simplest scheduling algorithm is First Come First Serve (FCFS). Jobs are
scheduled in the order they are received. FCFS is non-preemptive. Implementation is
easily accomplished by implementing a queue of the processes to be scheduled or by
storing the time the process was received and selecting the process with the earliest
time.

FCFS tends to favour CPU-Bound processes. Consider a system with a CPU-bound

process and a number of I/O-bound processes. The I/O bound processes will tend to
execute briefly, then block for I/O.ACPU bound process in the ready should not have
to wait long before being made runable. The system will frequently find itself with all
the I/O-Bound processes blocked and CPU-bound process running. As the I/O
operations complete, the ready Queue fill up with the I/O bound processes.

Under some circumstances, CPU utilisation can also suffer. In the situation described
above, once a CPU-bound process does issue an I/O request, the CPU can return to
process all the I/O-bound processes. If their processing completes before the CPU-
bound process’s I/O completes, the CPU sits idle. So with no preemption, component
utilisation and the system throughput rate may be quite low.

Example:

Calculate the turn around time, waiting time, average turnaround time, average waiting
time, throughput and processor utilization for the given set of processes that arrive at a
given arrive time shown in the table, with the length of processing time given in
milliseconds:
45
Introduction to Operating
Systems and Process
Management

If the processes arrive as per the arrival time, the Gantt chart will be

Average turn around time = (3+4+4+6+5) / 5 = 4.4

Average waiting time = (0+1+3+2+3) / 5 = 1.8
Processor utilization = (13/13)*100 = 100%
Throughput = 5/13 = 0.38

Note: If all the processes arrive at time 0, then the order of scheduling will be
P3, P5, P1, P2 and P4. By taking arrival time as 0 for all the processes, calculate
the above parameters and see the difference in the values.

2.5.2 Shortest-Job First (SJF)

This algorithm is assigned to the process that has smallest next CPU processing time,
when the CPU is available. In case of a tie, FCFS scheduling algorithm can be used. It
is originally implemented in a batch-processing environment. SJF relied on a time estimate
supplied with the batch job.
As an example, consider the following set of processes with the following processing
time which arrived at the same time.

Using SJF scheduling because the shortest length of process will first get execution, the
Gantt chart will be:

Because the shortest processing time is of the process P4, then process P1 and then
46
P3 and Process P2. The waiting time for process P1 is 3 ms, for process P2 is 16 ms, Processes
for process P3 is 9 ms and for the process P4 is 0 ms as –

Average turn around time = (3+9+16+24) / 4 = 13

Average waiting time = (0+3+9+16) / 4 = 7
Processor utilization = (24/24)*100 = 100%
Throughput = 4/24 = 0.16

2.5.3 Round Robin (RR)

Round Robin (RR) scheduling is a preemptive algorithm that relates the process that
has been waiting the longest. This is one of the oldest, simplest and widely used
algorithms. The round robin scheduling algorithm is primarily used in time-sharing and
a multi-user system environment where the primary requirement is to provide reasonably
good response times and in general to share the system fairly among all system users.
Basically the CPU time is divided into time slices.
Each process is allocated a small time-slice called quantum. No process can run for
more than one quantum while others are waiting in the ready queue. If a process needs
more CPU time to complete after exhausting one quantum, it goes to the end of ready
queue to await the next allocation. To implement the RR scheduling, Queue data structure
is used to maintain the Queue of Ready processes. A new process is added at the tail
of that Queue. The CPU schedular picks the first process from the ready Queue,
Allocate processor for a specified time Quantum. After that time the CPU schedular
will select the next process is the ready Queue.
Consider the following set of process with the processing time given in milliseconds.

If we use a time Quantum of 4 milliseconds then process P1 gets the first 4

milliseconds. Since it requires another 20 milliseconds, it is preempted after the first
time Quantum, and the CPU is given to the next process in the Queue, Process P2.
Since process P2 does not need and milliseconds, it quits before its time Quantum
expires. The CPU is then given to the next process, Process P3 one each process has
received 1 time Quantum, the CPU is returned to process P1 for an additional time
quantum. The Gantt chart will be:

47
Introduction to Operating
Systems and Process
Management

Average turn around time = (30+7+10)/3 = 47/3 = 15.66

Average waiting time = (6+4+7)/3 = 17/3 = 5.66
Throughput = 3/30 = 0.1
Processor utilization = (30/30) * 100 = 100%

2.5.4 Shortest Remaining Time Next (SRTN)

This is the preemptive version of shortest job first. This permits a process that enters
the ready list to preempt the running process if the time for the new process (or for its
next burst) is less than the remaining time for the running process (or for its current
burst). Let us understand with the help of an example.
Consider the set of four processes arrived as per timings described in the table:

At time 0, only process P1 has entered the system, so it is the process that executes.
At time 1, process P2 arrives. At that time, process P1 has 4 time units left to execute
At this juncture process 2’s processing time is less compared to the P1 left out time (4
units). So P2 starts executing at time 1. At time 2, process P3 enters the system with
the processing time 5 units. Process P2 continues executing as it has the minimum
number of time units when compared with P1 and P3.At time 3, process P2 terminates
and process P4 enters the system. Of the processes P1, P3 and P4, P4 has the smallest
remaining execution time so it starts executing. When process P1 terminates at time
10, process P3 executes. The Gantt chart is shown below:

Turnaround time for each process can be computed by subtracting the time it terminated
from the arrival time.
Turn around Time = t(Process Completed)– t(Process Submitted)
The turnaround time for each of the processes is:
P1: 10 – 0 = 10
P2: 3–1= 2
P3: 15 – 2 = 13
P4: 6–3= 3
48
The average turnaround time is (10+2+13+3) / 4 = 7 Processes

The waiting time can be computed by subtracting processing time from turnaround
time, yielding the following 4 results for the processes as
P1: 10 – 5 = 5
P2: 2 – 2 = 0
P3: 13 – 5 = 8
P4: 3 – 3 = 0
The average waiting time = (5+0+8+0) / 4 = 3.25milliseconds
Four jobs executed in 15 time units, so throughput is 15 / 4 = 3.75 time units/job.

2.5.5 Priority Based Scheduling or Event-Driven (ED)

Scheduling
A priority is associated with each process and the scheduler always picks up the highest
priority process for execution from the ready queue. Equal priority processes are
scheduled FCFS. The level of priority may be determined on the basis of resource
requirements, processes characteristics and its run time behaviour.
A major problem with a priority based scheduling is indefinite blocking of a lost priority
process by a high priority process. In general, completion of a process within finite
time cannot be guaranteed with this scheduling algorithm. A solution to the problem
of indefinite blockage of low priority process is provided by aging priority. Aging
priority is a technique of gradually increasing the priority of processes (of low
priority) that wait in the system for a long time. Eventually, the older processes attain
high priority and are ensured of completion in a finite time.
As an example, consider the following set of five processes, assumed to have arrived
at the same time with the length of processor timing in milliseconds: –

Using priority scheduling we would schedule these processes according to the following
Gantt chart:

49
Introduction to Operating Average turn around time = (1+6+16+18+19) / 5 = 60/5 = 12
Systems and Process
Management Average waiting time = (6+0+16+18+1) / 5 = 8.2
Throughput = 5/19 = 0.26
Processor utilization = (30/30) * 100 = 100%
Priorities can be defined either internally or externally. Internally defined priorities use
one measurable quantity or quantities to complete the priority of a process.

2.6 PERFORMANCE EVALUATION OF THE

SCHEDULING ALGORITHMS
Performance of an algorithm for a given set of processes can be analyzed if the
appropriate information about the process is provided. But how do we select a CPU-
scheduling algorithm for a particular system? There are many scheduling algorithms so
the selection of an algorithm for a particular system can be difficult. To select an
algorithm there are some specific criteria such as:

 Maximize CPU utilization with the maximum response time.

 Maximize throughput.

For example, assume that we have the following five processes arrived at time 0, in the
order given with the length of CPU time given in milliseconds.

First consider the FCFS scheduling algorithm for the set of processes.
For FCFS scheduling the Gantt chart will be:

Average Waiting Time: (0+10+39+42+49) / 5 = 28 milliseconds.

Now consider the SJF scheduling, the Gantt chart will be:

50
 Processes

Average Waiting Time: (10+32+0+3+20)/5 = 13 milliseconds.

Now consider the Round Robin scheduling algorithm with a quantum of 10 milliseconds.
The Gantt chart will be:

Average waiting time = (0+32+20+23+40) / 5 = 23 milliseconds

Now if we compare average waiting time above algorithms, we see that SJF policy
results in less than one half of the average waiting time to that of FCFS scheduling; the
RR algorithm gives us an intermediate value.
So performance of algorithm can be measured when all the necessary information is
provided.


Check Your Progress 3
1) Explainthe difference between voluntary or co-operative scheduling and preemptive
scheduling. Give two examples of preemptive and of non-preemptive scheduling
algorithms.
........................................................................................................................
........................................................................................................................
........................................................................................................................
........................................................................................................................

2) Outline how different process priorities can be implemented in a scheduling

algorithm. Explain why these priorities need to be dynamically adjusted.
........................................................................................................................
........................................................................................................................
........................................................................................................................
........................................................................................................................

3) Draw the Gantt chart for the FCFS policy, considering the following set of processes
that arrive at time 0, with the length of CPU time given in milliseconds.Also calculate
theAverage Waiting Time. 51
Introduction to Operating ........................................................................................................................
Systems and Process
Management
........................................................................................................................
........................................................................................................................
........................................................................................................................

Process Processing Time

P1 13
P2 08
P3 83

4) For the given five processes arriving at time 0, in the order with the length of CPU
time in milliseconds:

Process Processing Time

P1 10
P2 29
P3 03
P4 07

Consider the FCFS, SJF and RR (time slice= 10 milliseconds) scheduling algorithms
for the above set of process which algorithm would give the minimum average
waiting time?
........................................................................................................................
........................................................................................................................
........................................................................................................................

2.7 SUMMARY
A process is an instance of a program in execution. A process can be defined by the
system or process is an important concept in modem operating system. Processes
provide a suitable means for informing the operating system about independent activities
that may be scheduled for concurrent execution. Each process is represented by a
process control block (PCB). Several PCB’s can be linked together to form a queue
of waiting processes. The selection and allocation of processes is done by a scheduler.
There are several scheduling algorithms. We have discussed FCFS, SJF, RR, SJRT
and priority algorithms along with the performance evaluation.

2.8 SOLUTIONS/ANSWERS
Check Your Progress 1

52 1) A process is an instance of an executing program and its data. For example, if you
 were editing 3 files simultaneously, you would have 3 processes, even though they Processes
might be sharing the same code.
A thread is often called a lightweight process. It is a “child” and has all the state
information associated with a child process but does not run in a separate address
space i.e., doesn’t have its own memory. Since they share memory, each thread
has access to all variables and any change made by one thread impacts all the
others. Threads are useful in multi-client servers where each thread can service a
separate client connection. In some stand-alone processes where you can split the
processing such that one thread can continue processing while another is blocked
e.g., waiting for an I/O request or a timer thread can implement a regular repaint of
a graphics canvas.
This is how simple animations are accomplished in systems like NT and
Windows95. Unix is a single-threaded operating system and can’t do this at the
operating system level although some applications e.g., Java can support it via
software.
2) A process can be in one of the following states:

Ready i.e., in the scheduling queue waiting it’s turn for the CPU
Running i.e., currently occupying the CPU

Blocked i.e., sleeping waiting for a resource request to be satisfied.

Halted i.e., process execution is over.

 Aprocess moves from ready to running, when it is dispatched by the scheduler.

 Aprocess moves from running to ready, when it is pre-empted by the scheduler.
 A process moves from running to blocked when it issues a request for a
resource.
 A process moves from blocked to ready when completion of the request is
signaled.
3) A context switch occurs whenever a different process is moved into the CPU. The
current state of the existing process (register and stack contents, resources like
open files etc.) must be stored and the state of the new process restored. There is
a significant overhead in context switching. However, in a system with Virtual
Memory, some processes and some of the state information will be swapped to
disks. The overhead involved here is too great to undertake each quantum. Such
systems use a two-level scheduler. The high-level scheduler is responsible for
bring ready processes from disk into memory and adding them to ready queue.
This is done regularly (e.g., every 10 secs) but not each quantum (e.g., < every
100 msecs). The low level scheduler is responsible for the context switching between
CPU and ready queue.

Check Your Progress 2

1) Every process has a parent which invoked it. In the UNIX environment, the parent
can wait for the child to complete after invoking it (foreground child process) or
continue in a ready state (background child process).
53
Introduction to Operating 2) For each process, the operating system needs to maintain
Systems and Process
Management
 id information - process id, parent process id
 summary status - blocked, ready, running, swapped to disk
 owner information - user id, group id

 scheduling info - priority, nice value, CPU usage

 location info - resident or not, memory areas allocated
 state info - register values (instruction pointer etc.), stack, resources like open
files etc.

Check Your Progress 3

1) Preemptive multi-tasking means that the operating system decides when a process
has had its quantum of CPU, and removes it from the CPU to the ready queue.
This is present in UNIX, NT and Windows 95.
Voluntary and co-operative means that only the process itself decide to vacate the
CPU e.g., when it finishes or blocks on a request or yields the CPU. This is what
Windows3.x uses.
First Come First Served is a typical non-premptive algorithm.
Round Robin and Priority Queues are typical preemptive algorithms.
Shortest Job First can be either.

2) Some processes are more critical to overall operation than others e.g., kernel
activity. I/O bound processes, which seldom use a full quantum, need a boost
over compute bound tasks. This priority can be implemented by any combination
of higher positioning in the ready queue for higher priority more frequent occurrences
in the ready list for different priorities different quantum lengths for different
priorities. Priority scheduling is liable to starvation. Asuccession of high priority
processes may result in a low priority process never reaching the head of the
ready list. Priority is normal a combination of static priority (set by the user or the
class of the process) and a dynamic adjustment based on it’s history (e.g., how
long it has been waiting). NT and Linux also boost priority when processes return
from waiting for I/O.
3) If the process arrives in the order P1, P2 and P3, then the Gantt chart will be as:

Average Waiting Time: (0+13+21)/3 = 11.33 ms.

4) For FCFS algorithm the Gantt chart is as follows:
54
 Processes

Average Waiting Time = (0+10+39+42+49) / 5 = 5

2. With SJF scheduling algorithm, we have

Average Waiting Time = (10+32+00+03+20)/5 = 13 milliseconds.

With round robin scheduling algorithm (time quantum = 10 milliseconds)

Average Waiting Time = (0+32+20+23+40)/5 = 23 milliseconds.

From the above calculations of average waiting time we found that SJF policy results
in less than one half of the average waiting time obtained from FCFS, while Round
Robin gives intermediate result.

2.9 FURTHER READINGS

1) Abraham Silberschatz and James L, Operating system Concepts.
Peterson,Addition Wesely Publishing Company.
2) Andrew S. Tanenbaum, Operating System Design and Implementation,
PHI
3) D.M. Dhamdhere, Operating Systems, A Concept-based Approach, TMGH,
2002.
55
Introduction to Operating 4) Harvay M. Deital, Introduction to Operating Systems, Addition Wesely
Systems and Process
Management Publishing Company
5) Madnick and Donovan, Operating systems – Concepts and Design Mc GrawHill
Intl. Education.
6) Milan Milenkovic, Operating Systems, Concepts and Design, TMGH, 2000.

56
 Processes
UNIT 3 INTERPROCESS COMMUNICATION
AND SYNCHRONIZATION
Structure

3.1 Introduction
3.2 Objectives
3.3 Interprocess Communication
3.3.1 Shared-Memory System
3.3.2 Message-Passing System
3.4 Interprocess Synchronization
3.4.1 Serialization
3.4.2 Mutexes: Mutual Exclusion
3.4.3 Critical Sections: The Mutex Solution
3.4.4 Dekker’s Solution for Mutual Exclusion
3.4.5 Bakery’s Algorithm
3.5 Semaphores
3.6 Classical Problems in Concurrent Programming
3.6.1 Producers/Consumers Problem
3.6.2 Readers and Writers Problem
3.6.3 Dining- Philosophers Problem
3.6.4 Sleeping Barber Problem
3.7 Locks
3.8 Monitors and Condition Variables
3.9 Summary
3.10 Solution/Answers
3.11 Further Readings

3.1 INTRODUCTION
In the earlier unit we have studied the concept of processes. In addition to process
scheduling, another important responsibility of the operating system is process
synchronization. Synchronization involves the orderly sharing of system resources by
processes.
Concurrency specifies two or more sequential programs (a sequential program specifies
sequential execution of a list of statements) that may be executed concurrently as a
parallel process. For example, an airline reservation system that involves processing
transactions from many terminals has a natural specification as a concurrent program in
which each terminal is controlled by its own sequential process. Even when processes
are not executed simultaneously, it is often easier to structure as a collection of
cooperating sequential processes rather than as a single sequential program.
A simple batch operating system can be viewed as 3 processes-a reader process, an
executor process and a printer process. The reader reads cards from card reader and 57
Introduction to Operating places card images in an input buffer. The executor process reads card images from
Systems and Process
Management input buffer and performs the specified computation and store the result in an output
buffer. The printer process retrieves the data from the output buffer and writes them to
a printer. Concurrent processing is the basis of operating system which supports
multiprogramming.

The operating system supports concurrent execution of a program without necessarily

supporting elaborate form of memory and file management. This form of operation is
also known as multitasking. One of the benefits of multitasking is that several processes
can be made to cooperate in order to achieve their goals. To do this, they must do one
of the following:
Communicate: Interprocess communication (IPC) involves sending information from
one process to another. This can be achieved using a “mailbox” system, a socket
which behaves like a virtual communication network (loopback), or through the use of
“pipes”. Pipes are a system construction which enable one process to open another
process as if it were a file for writing or reading.

Share Data: A segment of memory must be available to both the processes. (Most
memory is locked to a single process).
Waiting: Some processes wait for other processes to give a signal before continuing.
This is an issue of synchronization.
In order to cooperate concurrently executing processes must communicate and
synchronize. Interprocess communication is based on the use of shared variables
(variables that can be referenced by more than one process) or message passing.

Synchronization is often necessary when processes communicate. Processes are

executed with unpredictable speeds. Yet to communicate one process must perform
some action such as setting the value of a variable or sending a message that the other
detects. This only works if the events perform an action or detect an action are
constrained to happen in that order. Thus one can view synchronization as a set of
constraints on the ordering of events. The programmer employs a synchronization
mechanism to delay execution of a process in order to satisfy such constraints.

In this unit, let us study the concept of interprocess communication and synchronization,
need of semaphores, classical problems in concurrent processing, critical regions,
monitors and message passing.

3.2 OBJECTIVES
After studying this unit, you should be able to:
 identify the significance of interprocess communication and synchronization;
 describe the two ways of interprocess communication namely shared memory
and message passing;
 discuss the usage of semaphores, locks and monitors in interprocess and
synchronization, and
 solve classical problems in concurrent programming.
58
 Interprocess Communication
3.3 INTERPROCESS COMMUNICATION and Synchronization

Interprocess communication (IPC) is a capability supported by operating system that

allows one process to communicate with another process. The processes can be running
on the same computer or on different computers connected through a network. IPC
enables one application to control another application, and for several applications to
share the same data without interfering with one another. IPC is required in all
multiprogramming systems, but it is not generally supported by single-process operating
systems such as DOS. OS/2 and MS-Windows support an IPC mechanism called
Dynamic Data Exchange.
IPC allows the process to communicate and to synchronize their actions without sharing
the same address space. This concept can be illustrated with the example of a shared
printer as given below:
Consider a machine with a single printer running a time-sharing operation system. If a
process needs to print its results, it must request that the operating system gives it
access to the printer’s device driver. At this point, the operating system must decide
whether to grant this request, depending upon whether the printer is already being
used by another process. If it is not, the operating system should grant the request and
allow the process to continue; otherwise, the operating system should deny the request
and perhaps classify the process as a waiting process until the printer becomes available.
Indeed, if two processes were given simultaneous access to the machine’s printer, the
results would be worthless to both.
Consider the following related definitions to understand the example in a better way:
Critical Resource: It is a resource shared with constraints on its use (e.g., memory,
files, printers, etc).
Critical Section: It is code that accesses a critical resource.
Mutual Exclusion:At most one process may be executing a critical section with respect
to a particular critical resource simultaneously.
In the example given above, the printer is the critical resource. Let’s suppose that the
processes which are sharing this resource are called process A and process B. The
critical sections of process A and process B are the sections of the code which issue
the print command. In order to ensure that both processes do not attempt to use the
printer at the same, they must be granted mutually exclusive access to the printer
driver.
First we consider the interprocess communication part. There exist two complementary
inter-process communication types: a) shared-memory system and b) message-
passing system. It is clear that these two schemes are not mutually exclusive, and could
be used simultaneously within a single operating system.

3.3.1 Shared-Memory System

Shared-memory systems require communication processes to share some variables.
The processes are expected to exchange information through the use of these shared
variables. In a shared-memory scheme, the responsibility for providing communication
rests with the application programmers. The operating system only needs to provide
shared memory. 59
Introduction to Operating A critical problem occurring in shared-memory system is that two or more processes
Systems and Process
Management are reading or writing some shared variables or shared data, and the final results depend
on who runs precisely and when. Such situations are called race conditions. In order
to avoid race conditions we must find some way to prevent more than one process
from reading and writing shared variables or shared data at the same time, i.e., we
need the concept of mutual exclusion (which we will discuss in the later section). It
must be sure that if one process is using a shared variable, the other process will be
excluded from doing the same thing.

3.3.2 Message-Passing System

Message passing systems allow communication processes to exchange messages. In
this scheme, the responsibility rests with the operating system itself.
The function of a message-passing system is to allow processes to communicate with
each other without the need to resort to shared variable.An interprocess communication
facility basically provides two operations: send (message) and receive (message). In
order to send and to receive messages, a communication link must exist between two
involved processes. This link can be implemented in different ways. The possible basic
implementation questions are:
 How are links established?
 Can a link be associated with more than two processes?
 How many links can there be between every pair of process?
 What is the capacity of a link? That is, does the link have some buffer space?
If so, how much?
 What is the size of the message? Can the link accommodate variable size or
fixed-size message?
 Is the link unidirectional or bi-directional?
In the following we consider several methods for logically implementing a communication
link and the send/receive operations. These methods can be classified into two categories:
a) Naming, consisting of direct and indirect communication and b) Buffering, consisting
of capacity and messages proprieties.

Direct Communication
In direct communication, each process that wants to send or receive a message must
explicitly name the recipient or sender of the communication. In this case, the send and
receive primitives are defined as follows:
 send (P, message) To send a message to process P
 receive (Q, message) To receive a message from process Q
This scheme shows the symmetry in addressing, i.e., both the sender and the receiver
have to name one another in order to communicate. In contrast to this, asymmetry in
addressing can be used, i.e., only the sender has to name the recipient; the recipient is
not required to name the sender. So the send and receive primitives can be defined as
follows:
60
  send (P, message) To send a message to the process P Interprocess Communication
and Synchronization
 receive (id, message) To receive a message from any process; id is set to
the name of the process with whom the
communication has taken place.
Indirect Communication
With indirect communication, the messages are sent to, and received from a mailbox.
A mailbox can be abstractly viewed as an object into which messages may be placed
and from which messages may be removed by processes. In order to distinguish one
from the other, each mailbox owns a unique identification.Aprocess may communicate
with some other process by a number of different mailboxes. The send and receive
primitives are defined as follows:
 send (A, message) To send a message to the mailbox A
 receive (A, message) To receive a message from the mailbox A
Mailboxes may be owned either by a process or by the system. If the mailbox is
owned by a process, then we distinguish between the owner who can only receive
from this mailbox and user who can only send message to the mailbox. When a process
that owns a mailbox terminates, its mailbox disappears. Any process that sends a
message to this mailbox must be notified in the form of an exception that the mailbox
no longer exists.
If the mailbox is owned by the operating system, then it has an existence of its own,
i.e., it is independent and not attached to any particular process. The operating system
provides a mechanism that allows a process to: a) create a new mailbox, b) send and
receive message through the mailbox and c) destroy a mailbox. Since all processes
with access rights to a mailbox may terminate, a mailbox may no longer be accessible
by any process after some time. In this case, the operating system should reclaim
whatever space was used for the mailbox.
Capacity Link
A link has some capacity that determines the number of messages that can temporarily
reside in it. This propriety can be viewed as a queue of messages attached to the link.
Basically there are three ways through which such a queue can be implemented:
Zero capacity: This link has a message queue length of zero, i.e., no message can
wait in it. The sender must wait until the recipient receives the message. The two
processes must be synchronized for a message transfer to take place. The zero-capacity
link is referred to as a message-passing system without buffering.
Bounded capacity: This link has a limited message queue length of n, i.e., at most n
messages can reside in it. If a new message is sent, and the queue is not full, it is placed
in the queue either by copying the message or by keeping a pointer to the message and
the sender should continue execution without waiting. Otherwise, the sender must be
delayed until space is available in the queue.
Unbounded capacity: This queue has potentially infinite length, i.e., any number of
messages can wait in it. That is why the sender is never delayed.
Bounded and unbounded capacity link provide message-passing system with automatic
buffering. 61
Introduction to Operating Messages
Systems and Process
Management
Messages sent by a process may be one of three varieties: a) fixed-sized, b) variable-
sized and c) typed messages. If only fixed-sized messages can be sent, the physical
implementation is straightforward. However, this makes the task of programming more
difficult. On the other hand, variable-size messages require more complex physical
implementation, but the programming becomes simpler.Typed messages, i.e., associating
a type with each mailbox, are applicable only to indirect communication. The messages
that can be sent to, and received from a mailbox are restricted to the designated type.

3.4 INTERPROCESS SYNCHRONIZATION

When two or more processes work on the same data simultaneously strange things
can happen. Suppose, when two parallel threads attempt to update the same variable
simultaneously, the result is unpredictable. The value of the variable afterwards depends
on which of the two threads was the last one to change the value. This is called a race
condition. The value depends on which of the threads wins the race to update the
variable. What we need in a mulitasking system is a way of making such situations
predictable. This is called serialization. Let us study the serialization concept in detail
in the next section.

3.4.1 Serialization
The key idea in process synchronization is serialization. This means that we have to
go to some pains to undo the work we have put into making an operating system
perform several tasks in parallel.As we mentioned, in the case of print queues, parallelism
is not always appropriate.
Synchronization is a large and difficult topic, so we shall only undertake to describe the
problem and some of the principles involved here.
There are essentially two strategies to serializing processes in a multitasking environment.
 The scheduler can be disabled for a short period of time, to prevent control
being given to another process during a critical action like modifying shared
data. This method is very inefficient on multiprocessor machines, since all
other processors have to be halted every time one wishes to execute a critical
section.
 A protocol can be introduced which all programs sharing data must obey.
The protocol ensures that processes have to queue up to gain access to shared
data. Processes which ignore the protocol ignore it at their own peril (and the
peril of the remainder of the system!). This method works on multiprocessor
machines also, though it is more difficult to visualize. The responsibility of
serializing important operations falls on programmers. The OS cannot impose
any restrictions on silly behaviour-it can only provide tools and mechanisms
to assist the solution of the problem.

3.4.2 Mutexes: Mutual Exclusion

When two or more processes must share some object, an arbitration mechanism is
needed so that they do not try to use it at the same time. The particular object being
62 shared does not have a great impact on the choice of such mechanisms. Consider the
62
following examples: two processes sharing a printer must take turns using it; if they Interprocess Communication
and Synchronization
attempt to use it simultaneously, the output from the two processes may be mixed into
an arbitrary jumble which is unlikely to be of any use. Two processes attempting to
update the same bank account must take turns; if each process reads the current
balance from some database, updates it, and then writes it back, one of the updates
will be lost.
Both of the above examples can be solved if there is some way for each process to
exclude the other from using the shared object during critical sections of code. Thus
the general problem is described as the mutual exclusion problem. The mutual exclusion
problem was recognized (and successfully solved) as early as 1963 in the Burroughs
AOSP operating system, but the problem is sufciently difcult widely understood for
some time after that. A signicant number of attempts to solve the mutual exclusion
problem have suffered from two specic problems, the lockout problem, in which a
subset of the processes can conspire to indenitely lock some other process out of a
critical section, and the deadlock problem, where two or more processes simultaneously
trying to enter a critical section lock each other out.
On a uni-processor system with non-preemptive scheduling, mutual exclusion is easily
obtained: the process which needs exclusive use of a resource simply refuses to relinquish
the processor until it is done with the resource. A similar solution works on a
preemptively scheduled uni-processor: the process which needs exclusive use of a
resource disables interrupts to prevent preemption until the resource is no longer
needed. These solutions are appropriate and have been widely used for short
critical sections, such as those involving updating a shared variable in main memory.
On the other hand, these solutions are not appropriate for long critical sections, for
example, those which involve input/ output. As a result, users are normally
forbidden to use these solutions; when they are used, their use is restricted to system
code.
Mutual exclusion can be achieved by a system of locks. A mutual exclusion lock is
colloquially called a mutex.You can see an example of mutex locking in the multithreaded
le reader in the previous section. The idea is for each thread or process to try to
obtain locked-access to shared data:
Get_Mutex(m);
// Update shared data
Release_Mutex(m);
This protocol is meant to ensure that only one process at a time can get past the
function Get_Mutex. All other processes or threads are made to wait at the function
Get_Mutex until that one process calls Release_Mutex to release the lock. A method
for implementing this is discussed below. Mutexes are a central part of multithreaded
programming.

3.4.3 Critical Sections: The Mutex Solution

A critical section is a part of a program in which is it necessary to have exclusive access
to shared data. Only one process or a thread may be in a critical section at any one
time. The characteristic properties of the code that form a Critical Section are:
· Codes that refer one or more variables in a “read-update-write” fashion while
any of those variables is possibly being altered by another thread. 63
Introduction to Operating  Codes that alter one or more variables that are possibly being referenced in
Systems and Process
Management “read-update-write” fashion by another thread.
 Codes use a data structure while any part of it is possibly being altered by
another thread.
 Codes alter any part of a data structure while it possibly in use by another
thread.
In the past it was possible to implement this by generalizing the idea of interrupt masks.
By switching off interrupts (or more appropriately, by switching off the scheduler) a
process can guarantee itself uninterrupted access to shared data. This method has
drawbacks:
i) Masking interrupts can be dangerous- there is always the possibility that
important interrupts will be missed;
ii) It is not general enough in a multiprocessor environment, since interrupts will
continue to be serviced by other processors-so all processors would have to
be switched off;
iii) It is too harsh. We only need to prevent two programs from being in their
critical sections simultaneously if they share the same data. Programs A and
B might share different data to programs C and D, so why should they wait
for C and D?
In 1981 G.L. Peterson discovered a simple algorithm for achieving mutual exclusion
between two processes with PID equal to 0 or 1. The code is as follows:
int turn;
int interested[2];
void Get_Mutex (int pid)
{
int other;
other = 1 - pid;
interested[process] = true;
turn = pid;
while (turn == pid && interested[other]) // Loop until no one
{ // else is interested
}
}
Release_Mutex (int pid)
{
interested[pid] = false;
}

Where more processes are involved, some modifications are necessary to this algorithm.
The key to serialization here is that, if a second process tries to obtain the mutex, when
64 another already has it, it will get caught in a loop, which does not terminate until the
other process has released the mutex. This solution is said to involve busy waiting-i.e., Interprocess Communication
and Synchronization
the program actively executes an empty loop, wasting CPU cycles, rather than moving
the process out of the scheduling queue. This is also called a spin lock, since the
system ‘spins’ on the loop while waiting. Let us see another algorithm which handles
critical section problem for n processes.

3.4.4 Dekker’s solution for Mutual Exclusion

Mutual exclusion can be assured even when there is no underlying mechanism such as
the test-and-set instruction. This was first realised by T. J. Dekker and published (by
Dijkstra) in 1965. Dekker’s algorithm uses busy waiting and works for only two
processes. The basic idea is that processes record their interest in entering a critical
section (in Boolean variables called “need”) and they take turns (using a variable called
“turn”) when both need entry at the same time. Dekker’s solution is shown below:
type processid = 0..1;
var need: array [ processid ] of boolean { initially false };
turn: processid { initially either 0 or 1 };
procedure dekkerwait( me: processid );
var other: processid;
begin
other := 1 - me;
need[ me ] := true;
while need[ other ] do begin { there is contention }
if turn = other then begin
need[ me ] := false { let other take a turn };
while turn = other do { nothing };
need[ me ] := true { re-assert my interest };
end;
end;
end { dekkerwait };
procedure dekkersignal( me: processid );
begin
need[ me ] := false;
turn := 1 - me { now, it is the other’s turn };
end { dekkersignal };
Dekkers solution to the mutual exclusion problem requires that each of the contending
processes have a unique process identifier which is called “me” which is passed to the
wait and signal operations.Although none of the previously mentioned solutions require
this, most systems provide some form of process identifier which can be used for this
purpose.

It should be noted that Dekker’s solution does rely on one very simple assumption
about the underlying hardware; it assumes that if two processes attempt to write two
different values in the same memory location at the same time, one or the other value
will be stored and not some mixture of the two. This is called the atomic update 65
Introduction to Operating assumption. The atomically updatable unit of memory varies considerably from one
Systems and Process
Management system to another; on some machines, any update of a word in memory is atomic, but
an attempt to update a byte is not atomic, while on others, updating a byte is atomic
while words are updated by a sequence of byte updates.

3.4.5 Bakery’s Algorithm

Bakery algorithm handles critical section problem for n processes as follows:
 Before entering its critical section, process receives a number. Holder of the smallest
number enters the critical section.

 If processes P i and P j receive the same number, if i < j , then P i is served first;
else P j is served first.
 The numbering scheme always generates numbers in increasing order of
enumeration; i.e., 1,2,3,3,3,3,4,5...
 Notation <= lexicographical order (ticket #, process id #)
o (a,b) < (c,d) if a < c or if a = c and b < d
o max(a , . . . , a ) is a number, k , such that k >= a for i = 0, . . . , n - 1
0 n-1i

 Shared data
boolean choosing[n]; //initialise all to false
int number[n]; //initialise all to 0
 Data structures are initialized to false and 0, respectively.
The algorithm is as follows:
do
{
choosing[i] = true;
number[i] = max(number[0], number[1], ...,number[n-1]) + 1;
choosing[i] = false;
for(int j = 0; j < n; j++)
{
while (choosing[j]== true)
{
/*do nothing*/
}
while ((number[j]!=0) &&
(number[j],j)< (number[i],i))
// see Reference point
{
/*do nothing*/
}
}
66
 do critical section Interprocess Communication
and Synchronization
number[i] = 0;
do remainder section
} while (true)
In the next section we will study how the semaphores provides a much more organize
approach of synchronization of processes.

3.4 SEMAPHORES
Semaphores provide a much more organized approach to controlling the interaction of
multiple processes than would be available if each user had to solve all interprocess
communications using simple variables, but more organization is possible. In a sense,
semaphores are something like the goto statement in early programming languages;
they can be used to solve a variety of problems, but they impose little structure on the
solution and the results can be hard to understand without the aid of numerous comments.
Just as there have been numerous control structures devised in sequential programs to
reduce or even eliminate the need for goto statements, numerous specialized concurrent
control structures have been developed which reduce or eliminate the need for
semaphores.
Definition: The effective synchronization tools often used to realize mutual exclusion
in more complex systems are semaphores. A semaphore S is an integer variable which
can be accessed only through two standard atomic operations: wait and signal. The
definition of the wait and signal operations are:
wait(S): while S < 0 do skip;
S := S – 1;
signal(S): S := S + 1;
or in C language notation we can write it as:
wait(s)
{
while (S<=0)
{
/*do nothing*/
}
S= S-1;
}
signal(S)
{
S = S + 1;
}
It should be noted that the test (S < 0) and modification of the integer value of S which
is S := S – 1 must be executed without interruption. In general, if one process modifies
the integer value of S in the wait and signal operations, no other process can
simultaneously modify that same S value. We briefly explain the usage of semaphores
in the following example:
67
Introduction to Operating Consider two currently running processes: P 1 with a statement S 1 and P 2 with a
Systems and Process
Management statement S2. Suppose that we require that S 2be executed only after S 1has completed.
This scheme can be implemented by letting P 1 and P2 share a common semaphore
synch, initialised to 0, and by inserting the statements:
S1;
signal(synch);
in the process P1 and the statements:
wait(synch);
S2;
in the process P 2.
Since synch is initialised to 0, P2 will execute S2 only after P1 has involved signal
(synch), which is after S1.
The disadvantage of the semaphore definition given above is that it requires busy-
waiting, i.e., while a process is in its critical region, any either process it trying to enter
its critical region must continuously loop in the entry code. It’s clear that through busy-
waiting, CPU cycles are wasted by which some other processes might use those
productively.
To overcome busy-waiting, we modify the definition of the wait and signal operations.
When a process executes the wait operation and finds that the semaphore value is not
positive, the process blocks itself. The block operation places the process into a waiting
state. Using a scheduler the CPU then can be allocated to other processes which are
ready to run.
A process that is blocked, i.e., waiting on a semaphore S, should be restarted by the
execution of a signal operation by some other processes, which changes its state from
blocked to ready. To implement a semaphore under this condition, we define a
semaphore as:
struct semaphore
{
int value;
List *L; //a list of processes
}
Each semaphore has an integer value and a list of processes. When a process must
wait on a semaphore, it is added to this list. A signal operation removes one process
from the list of waiting processes, and awakens it. The semaphore operation can be
now defined as follows:
wait(S)
{
S.value = S.value -1;
if (S.value <0)
{
add this process to S.L;
block;
68 }
 } Interprocess Communication
and Synchronization
signal(S)
{
S.value = S.value + 1;
if (S.value <= 0)
{
remove a process P from S.L;
wakeup(P);
}
}
The block operation suspends the process. The wakeup(P) operation resumes the
execution of a blocked process P. These two operations are provided by the operating
system as basic system calls.
One of the almost critical problem concerning implementing semaphore is the situation
where two or more processes are waiting indefinitely for an event that can be only
caused by one of the waiting processes: these processes are said to be deadlocked.
To illustrate this, consider a system consisting of two processes P1 and P2, each accessing
two semaphores S and Q, set to the value one:
P1 P2
wait(S); wait(Q);
wait(Q); wait(S);
... ...
signal(S); signal(Q);
signal(Q); signal(S);

Suppose P1 executes wait(S) and then P2 executes wait(Q). When P1 executes wait(Q),
it must wait until P 2 executes signal(Q). It is no problem, P 2 executes wait(Q), then
signal(Q). Similarly, when P2 executes wait(S), it must wait until P1 executes signal(S).
Thus these signal operations cannot be carried out, P 1 and P2 are deadlocked. It is
clear, that a set of processes are in a deadlocked state, when every process in the set
is waiting for an event that can only be caused by another process in the set.

3.5 CLASSICAL PROBLEMS IN

CONCURRENT PROGRAMMING
In this section, we present a large class of concurrency control problems. These
problems are used for testing nearly every newly proposed synchronization scheme.

3.5.1 Producers/Consumers Problem

Producer – Consumer processes are common in operating systems. The problem
definition is that, a producer (process) produces the information that is consumed by a
consumer (process). For example, a compiler may produce assembly code, which is
consumed by an assembler. A producer can produce one item while the consumer is 69
Introduction to Operating consuming another item. The producer and consumer must be synchronized. These
Systems and Process
Management problems can be solved either through unbounded buffer or bounded buffer.
 With an unbounded buffer
The unbounded-buffer producer- consumer problem places no practical limit on
the size of the buffer .The consumer may have to wait for new items, but the
producer can always produce new items; there are always empty positions in the
buffer.

 With a bounded buffer

The bounded buffer producer problem assumes that there is a fixed buffer size. In
this case, the consumer must wait if the buffer is empty and the producer must wait
if the buffer is full.

Shared Data
char item; //could be any data type
char buffer[n];
semaphore full = 0; //counting semaphore
semaphore empty = n; //counting semaphore
semaphore mutex = 1; //binary semaphore
char nextp,nextc;

Producer Process
do
{
produce an item in nextp
wait (empty);
wait (mutex);
add nextp to buffer
signal (mutex);
signal (full);
}
while (true)

Consumer Process
do
{
wait( full );
wait( mutex );
remove an item from buffer to nextc
signal( mutex );
signal( empty );
consume the item in nextc;
}
70
3.5.2 Readers and Writers Problem Interprocess Communication
and Synchronization
The readers/writers problem is one of the classic synchronization problems. It is often
used to compare and contrast synchronization mechanisms. It is also an eminently
used practical problem.Acommon paradigm in concurrent applications is isolation of
shared data such as a variable, buffer, or document and the control of access to that
data. This problem has two types of clients accessing the shared data. The first type,
referred to as readers, only wants to read the shared data. The second type, referred
to as writers, may want to modify the shared data. There is also a designated central
data server or controller. It enforces exclusive write semantics; if a writer is active then
no other writer or reader can be active. The server can support clients that wish to
both read and write. The readers and writers problem is useful for modeling processes
which are competing for a limited shared resource. Let us understand it with the help of
a practical example:
An airline reservation system consists of a huge database with many processes that
read and write the data. Reading information from the database will not cause a problem
since no data is changed. The problem lies in writing information to the database. If no
constraints are put on access to the database, data may change at any moment. By the
time a reading process displays the result of a request for information to the user, the
actual data in the database may have changed. What if, for instance, a process reads
the number of available seats on a flight, finds a value of one, and reports it to the
customer? Before the customer has a chance to make their reservation, another process
makes a reservation for another customer, changing the number of available seats to
zero.
The following is the solution using semaphores:
Semaphores can be used to restrict access to the database under certain conditions. In
this example, semaphores are used to prevent any writing processes from changing
information in the database while other processes are reading from the database.
semaphore mutex = 1; // Controls access to the reader count
semaphore db = 1; // Controls access to the database
int reader_count; // The number of reading processes accessing the data
Reader()
{
while (TRUE) { // loop forever
down(&mutex); // gain access to reader_count
reader_count = reader_count + 1; // increment the reader_count
if (reader_count == 1)
down(&db); //If this is the first process to read the database,
// a down on db is executed to prevent access to the
// database by a writing process
up(&mutex); // allow other processes to access reader_count
read_db(); // read the database
down(&mutex); // gain access to reader_count
reader_count = reader_count - 1; // decrement reader_count
if (reader_count == 0) 71
Introduction to Operating up(&db); // if there are no more processes reading from the
Systems and Process
Management // database, allow writing process to access the data
up(&mutex); // allow other processes to access
reader_countuse_data();
// use the data read from the database (non-critical)
}
Writer()
{
while (TRUE) { // loop forever
create_data(); // create data to enter into database (non-critical)
down(&db); // gain access to the database
write_db(); // write information to the database
up(&db); // release exclusive access to the database
}

3.5.3 Dining- Philosophers Problem

Five philosophers sit around a circular table. Each philosopher spends his life alternatively
thinking and eating. In the centre of the table is a large bowl of rice. A philosopher
needs two chopsticks to eat. Only 5 chop sticks are available and a chopstick is
placed between each pair of philosophers. They agree that each will only use the
chopstick to his immediate right and left. From time to time, a philosopher gets hungry
and tries to grab the two chopsticks that are immediate left and right to him. When a
hungry philosopher has both his chopsticks at the same time, he eats without releasing
his chopsticks. When he finishes eating, he puts down both his chopsticks and starts
thinking again.
Here’s a solution for the problem which does not require a process to write another
process’s state, and gets equivalent parallelism.
#define N 5 /* Number of philosphers */
#define RIGHT(i) (((i)+1) %N)
#define LEFT(i) (((i)==N) ? 0 : (i)+1)
typedef enum { THINKING, HUNGRY, EATING } phil_state;
phil_state state[N];
semaphore mutex =1;
semaphore s[N];
/* one per philosopher, all 0 */
void get_forks(int i) {
state[i] = HUNGRY;
while ( state[i] == HUNGRY ) {
P(mutex);
if ( state[i] == HUNGRY &&
state[LEFT] != EATING &&
state[RIGHT(i)] != EATING ) {
72 state[i] = EATING;
 V(s[i]); Interprocess Communication
and Synchronization
}
V(mutex);
P(s[i]);
}
}
void put_forks(int i) {
P(mutex);
state[i]= THINKING;
if ( state[LEFT(i)] == HUNGRY ) V(s[LEFT(i)]);
if ( state[RIGHT(i)] == HUNGRY) V(s[RIGHT(i)]);
V(mutex);
}
void philosopher(int process) {
while(1) {
think();
get_forks(process);
eat();
put_forks();
}
}

3.5.4 Sleeping Barber Problem

A barber shop consists of a waiting room with chairs, and the barber room containing
the barber chair. If there are no customers to be served, the barber goes to sleep. If a
customer enters the barber shop and all chairs are occupied, then the customer leaves
the shop. if the barber is busy, but chairs are available, then the customer sits in one of
the free chairs. If the barber is asleep, the customer wakes up the barber.
The following is a sample solution for the sleeping barber problem.
# define CHAIRS 5 // chairs for waiting customers
typedef int semaphore; // use this for imagination
semaphore customers = 0; // number of customers waiting for service
semaphore barbers – 0; // number of barbers waiting for customers
semaphore mutex = 1; // for mutual exclusion
int waiting = 0; //customers who are waiting for a haircut
void barber(void)
{
while (TRUE) {
down(&customers); //go to sleep if no of customers are zero
down(&mutex); //acquire access to waiting
waiting = waiting -1 ; //decrement count of waiting customers 73
Introduction to Operating up(&barbers); //one barber is now ready for cut hair
Systems and Process
Management up(&mutex); //release waiting
cut_hair(); //this is out of critical region for hair cut
}
}
void customer(void)
{
down(&mutex); //enter critical region
if (waiting < CHAIRS) //if there are no free chairs, leave
{
waiting = waiting +1; //increment count of waiting customers
up(&customers); //wake up barber if necessary
up(&mutex); //release access to waiting
down(&barbers); //go to sleep if no of free barbers is zero
get_haircut(); //be seated and be serviced
} else
{
up (&mutex); // shop is full: do no wait
}
}
Explanation:
 This problem is similar to various queuing situations
 The problem is to program the barber and the customers without getting into race
conditions
– Solution uses three semaphores:
 customers; counts the waiting customers
 barbers; the number of barbers (0 or 1)
 mutex; used for mutual exclusion
 also need a variable waiting; also counts the waiting customers; (reason;
no way to read the current value of semaphore)
– The barber executes the procedure barber, causing him to block on the
semaphore customers (initially 0);
– The barber then goes to sleep;
– When a customer arrives, he executes customer, starting by acquiring mutex
to enter a critical region;
– If another customer enters, shortly thereafter, the second one will not be able
to do anything until the first one has released mutex;
– The customer then checks to see if the number of waiting customers is less
74 than the number of chairs;
 – If not, he releases mutex and leaves without a haircut; Interprocess Communication
and Synchronization
– If there is an available chair, the customer increments the integer variable,
waiting;
– Then he does an up on the semaphore customers;
– When the customer releases mutex, the barber begins the haircut.

3.6 LOCKS
Locks are another synchronization mechanism. A lock has got two atomic
operations (similar to semaphore) to provide mutual exclusion. These two operations
are Acquire and Release. A process will acquire a lock before accessing a shared
variable, and later it will be released. A process locking a variable will run the
following code:
Lock-Acquire();
critical section
Lock-Release();
The difference between a lock and a semaphore is that a lock is released only by the
process that have acquired it earlier.As we discussed above any process can increment
the value of the semaphore. To implement locks, here are some things you should keep
inmind:
· To make Acquire () and Release () atomic
· Build a wait mechanism.
· Making sure that only the process that acquires the lock will release the lock.

3.7 MONITORS AND CONDITION VARIABLES

When you are using semaphores and locks you must be very careful, because a simple
misspelling may lead that the system ends up in a deadlock. Monitors are written to
make synchronization easier and correctly. Monitors are some procedures, variables,
and data structures grouped together in a package.
An early proposal for organising the operations required to establish mutual exclusion
is the explicit critical section statement. In such a statement, usually proposed in the
form “critical x do y”, where “x” is the name of a semaphore and “y” is a statement, the
actual wait and signal operations used to ensure mutual exclusion were implicit and
automatically balanced. This allowed the compiler to trivially check for the most obvious
errors in concurrent programming, those where a wait or signal operation was
accidentally forgotten. The problem with this statement is that it is not adequate for
many critical sections.
A common observation about critical sections is that many of the procedures for
manipulating shared abstract data types such as les have critical sections making up
their entire bodies. Such abstract data types have come to be known as monitors, a
term coined by C. A. R. Hoare. Hoare proposed a programming notation where the
critical sections and semaphores implicit in the use of a monitor were all implicit. All 75
Introduction to Operating that this notation requires is that the programmer encloses the declarations of the
Systems and Process
Management procedures and the representation of the data type in a monitor block; the compiler
supplies the semaphores and the wait and signal operations that this implies. Using
Hoare’s suggested notation, shared counters might be implemented as shown below:
var value: integer;
procedure increment;
begin
value := value + 1;
end { increment };
end { counter };
var i, j: counter;
Calls to procedures within the body of a monitor are done using record notation; thus,
to increment one of the counters declared in above example, one would call
“i.increment”. This call would implicitly do a wait operation on the semaphore implicitly
associated with “i”, then execute the body of the “increment” procedure before doing
a signal operation on the semaphore. Note that the call to “i.increment” implicitly passes
a specific instance of the monitor as a parameter to the “increment” procedure, and
that fields of this instance become global variables to the body of the procedure, as if
there was an implicit “with” statement.
There are a number of problems with monitors which have been ignored in the above
example. For example, consider the problem of assigning a meaning to a call from
within one monitor procedure to a procedure within another monitor. This can easily
lead to a deadlock. For example, when procedures within two different monitors each
calling the other. It has sometimes been proposed that such calls should never be
allowed, but they are sometimes useful! We will study more on deadlocks in the next
units of this course.
The most important problem with monitors is that of waiting for resources when they
are not available. For example, consider implementing a queue monitor with internal
procedures for the enqueue and dequeue operations. When the queue empties, a call
to dequeue must wait, but this wait must not block further entries to the monitor through
the enqueue procedure. In effect, there must be a way for a process to temporarily
step outside of the monitor, releasing mutual exclusion while it waits for some other
process to enter the monitor and do some needed action.
Hoare’s suggested solution to this problem involves the introduction of condition
variables which may be local to a monitor, along with the operations wait and signal.
Essentially, if s is the monitor semaphore, and c is a semaphore representing a condition
variable, “wait c” is equivalent to “signal(s); wait(c); wait(s)” and “signal c” is equivalent
to “signal(c)”. The details of Hoare’s wait and signal operations were somewhat more
complex than is shown here because the waiting process was given priority over other
processes trying to enter the monitor, and condition variables had no memory; repeated
signalling of a condition had no effect and signaling a condition on which no process
was waiting had no effect. Following is an example monitor:
monitor synch
integer i;
76 condition c;
 procedure producer(x); Interprocess Communication
and Synchronization
.
.
end;
procedure consumer(x);
.
.
end;
end monitor;
There is only one process that can enter a monitor, therefore every monitor has its own
waiting list with process waiting to enter the monitor.
Let us see the dining philosopher’s which was explained in the above section with
semaphores, can be re-written using the monitors as:
Example: Solution to the Dining Philosophers Problem using Monitors
monitor dining-philosophers
{
enum state {thinking, hungry, eating};
state state[5];
condition self[5];
void pickup (int i)
{
state[i] = hungry;
test(i);
if (state[i] != eating)
self[i].wait;
}
void putdown (int i)
{
state[i] = thinking;
test(i+4 % 5);
test(i+1 % 5);
}
void test (int k)
{
if ((state[k+4 % 5] != eating) && (state[k]==hungry)
&& state[k+1 % 5] != eating))
{
state[k] = eating;
self[k].signal;
}
} 77
Introduction to Operating init
Systems and Process
Management {
for (int i = 0; i< 5; i++)
state[i] = thinking;
}
}
Condition Variables
If a process cannot enter the monitor it must block itself. This operation is provided by
the condition variables. Like locks and semaphores, the condition has got a wait and a
signal function. But it also has the broadcast signal. Implementation of condition variables
is part of a synch.h; it is your job to implement it. Wait (), Signal () and Broadcast ()
have the following semantics:
 Wait() releases the lock, gives up the CPU until signaled and then re-acquire
the lock.
 Signal() wakes up a thread if there are any waiting on the condition variable.
 Broadcast() wakes up all threads waiting on the condition.
When you implement the condition variable, you must have a queue for the processes
waiting on the condition variable.


Check Your Progress 1
1) What are race conditions? How race conditions occur in Operating Systems?
........................................................................................................................
........................................................................................................................

2) What is a critical section? Explain.

........................................................................................................................
........................................................................................................................

3) Provide the solution to a classical synchronization problem namely “cigarette

smoker’s problem”. The problem is defined as follows:
There are four processes in this problem: three smoker processes and an
agent process. Each of the smoker processes will make a cigarette and smoke
it. To make a cigarette requires tobacco, paper, and matches. Each smoker
process has one of the three items. i.e., one process has tobacco, another has
paper, and a third has matches. The agent has an infinite supply of all three.
The agent places two of the three items on the table, and the smoker that has
the third item makes the cigarette.
........................................................................................................................
........................................................................................................................

3.8 SUMMARY
Interprocess communication provides a mechanism to allow process to communicate
78 with other processes. Interprocess communication system is best provided by a message
passing system. Message systems can be defined in many different ways. If there are a Interprocess Communication
and Synchronization
collection of cooperating sequential processes that share some data, mutual exclusion
must be provided. There are different methods for achieving the mutual exclusion.
Different algorithms are available for solving the critical section problem which we
have discussion in this unit. The bakery algorithm is used for solving the n process
critical section problem.
Interprocess synchronization provides the processes to synchronize their activities.
Semaphores can be used to solve synchronization problems. Semaphore can only be
accessed through two atomic operations and can be implemented efficiently. The two
operations are wait and signal.
There are a number of classical synchronization problems which we have discussed in
this unit (such as producer- consumer problem, readers – writers problem and d dining
– philosophers problem). These problems are important mainly because they are
examples for a large class of concurrency-control problems. In the next unit we will
study an important aspect called as “Deadlocks”

3.9 SOLUTIONS/ANSWERS
Check Your Progress 1
1) Processes that are working together share some common storage (main memory,
file etc.) that each process can read and write. When two or more processes are
reading or writing some shared data and the final result depends on who runs
precisely when, are called race conditions. Concurrently executing threads that
share data need to synchronize their operations and processing in order to avoid
race condition on shared data. Only one “customer” thread at a time should be
allowed to examine and update the shared variable.
Race conditions are also possible in Operating Systems. If the ready queue is
implemented as a linked list and if the ready queue is being manipulated during the
handling of an interrupt, then interrupts must be disabled to prevent another interrupt
before the first one completes. If interrupts are not disabled than the linked list
could become corrupt.
2) The most synchronization problem confronting cooperating processes, is to control
the access between the shared resources. Suppose two processes share access
to a file and at least one of these processes can modify the data in this shared area
of memory. That part of the code of each program, where one process is reading
from or writing to a shared memory area, is a critical section of code; because
we must ensure that only one process execute a critical section of code at a time.
The critical section problem is to design a protocol that the processes can use to
coordinate their activities when one wants to enter its critical section of code.
3) This seems like a fairly easy solution. The three smoker processes will make a
cigarette and smoke it. If they can’t make a cigarette, then they will go to sleep.
The agent process will place two items on the table, and wake up the appropriate
smoker, and then go to sleep. All semaphores except lock are initialised to 0.
Lock is initialised to 1, and is a mutex variable.
Here’s the code for the agent process.
do forever {
P( lock ); 79
Introduction to Operating randNum = rand(1,3); // Pick a random number from 1-3
Systems and Process
Management if (randNum == 1) {
// Put tobacco on table
// Put paper on table
V(smoker_match); // Wake up smoker with match
}
else if (randNum == 2) {
// Put tobacco on table
// Put match on table
V(smoker_paper); // Wake up smoker with paper
}
else {
// Put match on table
// Put paper on table
V(smoker_tobacco);
} // Wake up smoker with tobacco
V(lock);
P(agent); // Agent sleeps
} // end forever loop
The following is the code for one of the smokers. The others are analogous.
do forever {
P(smoker_tobacco); // Sleep right away
P(lock);
// Pick up match
// Pick up paper
V(agent);
V(lock);
// Smoke
}

3.10 FURTHER READINGS

1) Milenkovic, Milan, “Operating Systems Concepts and Design”, McGraw-Hill,
2nd Edition.
2) Tanenbaum, Andrew, Modern Operating Systems, Prentice-Hall.
3) Silberschatz,Abraham and Galvin Peter, “Operating System Concepts”,Addison-
Wesley.
4) D.M. Dhamdhere, “Operating Systems A concept-based Approach”, Tata
McGraw-Hill.
5) William Stalling, “Operating System”, Prentice Hall.
6) Deitel, Harvey M. , “An introduction to Operating System”, 4th ed., Addison-
80 Wesley.
 Interprocess Communication
UNIT 4 DEADLOCKS and Synchronization

Structure

4.1 Introduction
4.2 Objectives
4.3 Deadlocks
4.4 Characterization of a Deadlock
4.4.1 Mutual Exclusion Condition
4.4.2 Hold and Wait Condition
4.4.3 No-Preemptive Condition
4.4.4 Circular Wait Condition
4.5 Resource Allocation Graph
4.6 Dealing with Deadlock Situations
4.6.1 Deadlock Prevention
4.6.2 Deadlock Avoidance
4.6.3 Deadlock Detection and Recovery
4.7 Summary
4.8 Solutions/Answers
4.9 Further Readings

4.1 INTRODUCTION
In a computer system, we have a finite number of resources to be distributed among a
number of competing processes. These system resources are classified in several types
which may be either physical or logical. Examples of physical resources are Printers,
Tape drivers, Memory space, and CPU cycles. Examples of logical resources are
Files, Semaphores and Monitors. Each resource type can have some identical instances.
A process must request a resource before using it and release the resource after using
it. It is clear that the number of resources requested cannot exceed the total number of
resources available in the system.
In a normal operation, a process may utilize a resource only in the following sequence:
 Request: if the request cannot be immediately granted, then the requesting process
must wait until it can get the resource.
 Use: the requesting process can operate on the resource.
 Release: the process releases the resource after using it.
Examples for request and release of system resources are:
 Request and release the device,
 Opening and closing file,
 Allocating and freeing the memory.
81
Introduction to Operating The operating system is responsible for making sure that the requesting process has
Systems and Process
Management been allocated the resource.Asystem table indicates if each resource is free or allocated,
and if allocated, to which process. If a process requests a resource that is currently
allocated to another process, it can be added to a queue of processes waiting for this
resource.
In some cases, several processes may compete for a fixed number of resources. A
process requests resources and if the resources are not available at that time, it enters
a wait state. It may happen that it will never gain access to the resources, since those
resources are being held by other waiting processes.
For example, assume a system with one tape drive and one plotter. Process P1 requests
the tape drive and process P2 requests the plotter. Both requests are granted. Now PI
requests the plotter (without giving up the tape drive) and P2 requests the tape drive
(without giving up the plotter). Neither request can be granted so both processes enter
a situation called the deadlock situation.
A deadlock is a situation where a group of processes is permanently blocked as a
result of each process having acquired a set of resources needed for its completion
and having to wait for the release of the remaining resources held by others thus making
it impossible for any of the deadlocked processes to proceed.
In the earlier units, we have gone through the concept of process and the need for the
interprocess communication and synchronization. In this unit we will study about the
deadlocks, its characterisation, deadlock avoidance and its recovery.

4.2 OBJECTIVES
After going through this unit, you should be able to:
 define a deadlock;
 understand the conditions for a deadlock;
 know the ways of avoiding deadlocks, and
 describe the ways to recover from the deadlock situation.

4.3 DEADLOCKS
Before studying about deadlocks, let us look at the various types of resources. There
are two types of resources namely: Pre-emptable and Non-pre-emptable Resources.
 Pre-emptable resources: This resource can be taken away from the process
with no ill effects. Memory is an example of a pre-emptable resource.
 Non-Preemptable resource: This resource cannot be taken away from the
process (without causing ill effect). For example, CD resources are not preemptable
at an arbitrary moment.
Reallocating resources can resolve deadlocks that involve preemptable resources.
Deadlocks that involve nonpreemptable resources are difficult to deal with. Let us see
how a deadlock occurs.
Definition: A set of processes is in a deadlock state if each process in the set is
82 waiting for an event that can be caused by only another process in the set. In other
words, each member of the set of deadlock processes is waiting for a resource that Deadlocks
can be released only by a deadlock process. None of the processes can run, none of
them can release any resources and none of them can be awakened. It is important to
note that the number of processes and the number and kind of resources possessed
and requested are unimportant.
Let us understand the deadlock situation with the help of examples.
Example 1: The simplest example of deadlock is where process 1 has been allocated
a non-shareable resource A, say, a tap drive, and process 2 has been allocated a non-
sharable resource B, say, a printer. Now, if it turns out that process 1 needs resource
B (printer) to proceed and process 2 needs resource A (the tape drive) to proceed and
these are the only two processes in the system, each has blocked the other and all
useful work in the system stops. This situation is termed as deadlock.
The system is in deadlock state because each process holds a resource being requested
by the other process and neither process is willing to release the resource it holds.
Example 2: Consider a system with three disk drives. Suppose there are three
processes, each is holding one of these three disk drives. If each process now requests
another disk drive, three processes will be in a deadlock state, because each process
is waiting for the event “disk drive is released”, which can only be caused by one of the
other waiting processes. Deadlock state involves processes competing not only for the
same resource type, but also for different resource types.
Deadlocks occur most commonly in multitasking and client/server environments and
are also known as a “Deadly Embrace”. Ideally, the programs that are deadlocked or
the operating system should resolve the deadlock, but this doesn’t always happen.
From the above examples, we have understood the concept of deadlocks. In the
examples we were given some instances, but we will study the necessary conditions
for a deadlock to occur, in the next section.

4.4 CHARACTERIZATION OF A DEADLOCK

Coffman (1971) identified four necessary conditions that must hold simultaneously
for a deadlock to occur.

4.4.1 Mutual Exclusion Condition

The resources involved are non-shareable. At least one resource must be held in a
non-shareable mode, that is, only one process at a time claims exclusive control of the
resource. If another process requests that resource, the requesting process must be
delayed until the resource has been released.

4.4.2 Hold and Wait Condition

In this condition, a requesting process already holds resources and waiting for the
requested resources. A process, holding a resource allocated to it waits for an
additional resource(s) that is/are currently being held by other processes.

4.4.3 No-Preemptive Condition

Resources already allocated to a process cannot be preempted. Resources cannot be 83
Introduction to Operating removed forcibly from the processes.After completion, they will be released voluntarily
Systems and Process
Management by the process holding it.

4.4.4 Circular Wait Condition

The processes in the system form a circular list or chain where each process in the list
is waiting for a resource held by the next process in the list.
Let us understand this by a common example. Consider the traffic deadlock shown in
the Figure 1.

Figure 1: Traffic Deadlock

Consider each section of the street as a resource. In this situation:

 Mutual exclusion condition applies, since only one vehicle can be on a section of
the street at a time.
 Hold-and-wait condition applies, since each vehicle is occupying a section of the
street, and waiting to move on to the next section of the street.
 Non-preemptive condition applies, since a section of the street that is occupied by
a vehicle cannot be taken away from it.
 Circular wait condition applies, since each vehicle is waiting for the next vehicle to
move. That is, each vehicle in the traffic is waiting for a section of the street held by
the next vehicle in the traffic.
The simple rule to avoid traffic deadlock is that a vehicle should only enter an intersection
if it is assured that it will not have to stop inside the intersection.
It is not possible to have a deadlock involving only one single process. The deadlock
involves a circular “hold-and-wait” condition between two or more processes, so
“one” process cannot hold a resource, yet be waiting for another resource that it is
holding. In addition, deadlock is not possible between two threads in a process, because
it is the process that holds resources, not the thread, that is, each thread has access to
the resources held by the process.

4.4 RESOURCE ALLOCATION GRAPH

The idea behind the resource allocation graph is to have a graph which has two different
types of nodes, the process nodes and resource nodes (process represented by circles,
resource node represented by rectangles). For different instances of a resource, there
84
is a dot in the resource node rectangle. For example, if there are two identical printers, Deadlocks

the printer resource might have two dots to indicate that we don’t really care which is
used, as long as we acquire the resource.

The edges among these nodes represent resource allocation and release. Edges are
directed, and if the edge goes from resource to process node that means the process
has acquired the resource. If the edge goes from process node to resource node that
means the process has requested the resource.

We can use these graphs to determine if a deadline has occurred or may occur. If for
example, all resources have only one instance (all resource node rectangles have one
dot) and the graph is circular, then a deadlock has occurred. If on the other hand some
resources have several instances, then a deadlock may occur. If the graph is not circular,
a deadlock cannot occur (the circular wait condition wouldn’t be satisfied).

The following are the tips which will help you to check the graph easily to predict the
presence of cycles.

 If no cycle exists in the resource allocation graph, there is no deadlock.

 If there is a cycle in the graph and each resource has only one instance, then there
is a deadlock. In this case, a cycle is a necessary and sufficient condition for
deadlock.

 If there is a cycle in the graph, and each resource has more than one instance,
there may or may not be a deadlock. (A cycle may be broken if some process
outside the cycle has a resource instance that can break the cycle). Therefore, a
cycle in the resource allocation graph is a necessary but not sufficient condition for
deadlock, when multiple resource instances are considered.

Example:

Figure 2: Resource Allocation Graph Showing Deadlock

The above graph shown in Figure 2 has a cycle and is in Deadlock.

85
Introducti
Introduction
on to Operating
Systems and
and Process
Management
Managem ent

Figure 3: Resource Allocation Graph having a cycle and not in a Deadlock

The above graph shown in Figure 3 has a cycle and is not in Deadlock.
(Resource 1 has one instance shown by a star)
(Resource 2 has two instances a and b, shown as two stars)

R1 P1 P1 R2 (a)

R2 (b) P2 P2 R1
If P1 finishes, P2 can get R1 and finish, so there is no Deadlock.

4.5 DEALING WITH DEADLOCK SITUATIONS

There are possible strategies to deal with deadlocks. They are:

 Deadlock Prevention

 Deadlock Avoidance

 Deadlock Detection and Recovery

Let’s examine each strategy one by one to evaluate their respective strengths and
weaknesses.

4.5.1 Deadlock Prevention

Havender in his pioneering work showed that since all four of the conditions are
necessary for deadlock to occur, it follows that deadlock might be prevented by denying
any one of the conditions. Let us study Havender’s algorithm.

Havender’s Algorithm
Elimination of “Mutual Exclusion” Condition
The mutual exclusion condition must hold for non-shareable resources. That is, several
processes cannot simultaneously share a single resource. This condition is difficult to
eliminate because some resources, such as the tap drive and printer, are inherently
non-shareable. Note that shareable resources like read-only-file do not require mutually
exclusive access and thus cannot be involved in deadlock.
86
Elimination of “Hold and Wait” Condition Deadlocks

There are two possibilities for the elimination of the second condition. The first alternative
is that a process request be granted all the resources it needs at once, prior to execution.
The second alternative is to disallow a process from requesting resources whenever it
has previously allocated resources. This strategy requires that all the resources a process
will need must be requested at once. The system must grant resources on “all or
none” basis. If the complete set of resources needed by a process is not currently
available, then the process must wait until the complete set is available. While the
process waits, however, it may not hold any resources. Thus the “wait for” condition is
denied and deadlocks simply cannot occur. This strategy can lead to serious waste of
resources.

For example, a program requiring ten tap drives must request and receive all ten drives
before it begins executing. If the program needs only one tap drive to begin execution
and then does not need the remaining tap drives for several hours then substantial
computer resources (9 tape drives) will sit idle for several hours. This strategy can
cause indefinite postponement (starvation), since not all the required resources may
become available at once.

Elimination of “No-preemption” Condition

The nonpreemption condition can be alleviated by forcing a process waiting for a

resource that cannot immediately be allocated, to relinquish all of its currently held
resources, so that other processes may use them to finish their needs. Suppose a
system does allow processes to hold resources while requesting additional resources.
Consider what happens when a request cannot be satisfied. A process holds
resources a second process may need in order to proceed, while the second
process may hold the resources needed by the first process. This is a deadlock.
This strategy requires that when a process that is holding some resources is denied
a request for additional resources, the process must release its held resources and, if
necessary, request them again together with additional resources. Implementation
of this strategy denies the “no-preemptive” condition effectively.

High Cost

When a process releases resources, the process may lose all its work to that point.
One serious consequence of this strategy is the possibility of indefinite postponement
(starvation).A process might be held off indefinitely as it repeatedly requests and
releases the same resources.

Elimination of “Circular Wait” Condition

The last condition, the circular wait, can be denied by imposing a total ordering on all
of the resource types and than forcing all processes to request the resources in order
(increasing or decreasing). This strategy imposes a total ordering of all resource types,
and requires that each process requests resources in a numerical order of enumeration.
With this rule, the resource allocation graph can never have a cycle.

For example, provide a global numbering of all the resources, as shown in the given
Table 1:
87
Introduction to Operating Table 1: Numbering the resources
Systems and Process
Management
Number Resource
1 Floppy drive
2 Printer
3 Plotter
4 Tape Drive
5 CD Drive

Now we will see the rule for this:

Rule: Processes can request resources whenever they want to, but all requests must
be made in numerical order. A process may request first printer and then a tape drive
(order: 2, 4), but it may not request first a plotter and then a printer (order: 3, 2). The
problem with this strategy is that it may be impossible to find an ordering that satisfies
everyone.
This strategy, if adopted, may result in low resource utilization and in some cases
starvation is possible too.

4.5.2 Deadlock Avoidance

This approach to the deadlock problem anticipates a deadlock before it actually occurs.
This approach employs an algorithm to access the possibility that deadlock could
occur and act accordingly. This method differs from deadlock prevention, which
guarantees that deadlock cannot occur by denying one of the necessary conditions of
deadlock. The most famous deadlock avoidance algorithm, from Dijkstra [1965], is
the Banker’s algorithm. It is named as Banker’s algorithm because the process is
analogous to that used by a banker in deciding if a loan can be safely made a not.
The Banker’s Algorithm is based on the banking system, which never allocates its
available cash in such a manner that it can no longer satisfy the needs of all its customers.
Here we must have the advance knowledge of the maximum possible claims for each
process, which is limited by the resource availability. During the run of the system we
should keep monitoring the resource allocation status to ensure that no circular wait
condition can exist.
If the necessary conditions for a deadlock are in place, it is still possible to avoid
deadlock by being careful when resources are allocated. The following are the features
that are to be considered for avoidance of the deadlock s per the Banker’s Algorithms.

 Each process declares maximum number of resources of each type that it may
need.
 Keep the system in a safe state in which we can allocate resources to each process
in some order and avoid deadlock.

 Check for the safe state by finding a safe sequence: <P1, P2, ..., Pn> where
resources that Pi needs can be satisfied by available resources plus resources held
by Pj where j < i.
88
 Resource allocation graph algorithm uses claim edges to check for a safe state. Deadlocks

The resource allocation state is now defined by the number of available and allocated
resources, and the maximum demands of the processes. Subsequently the system can
be in either of the following states:
 Safe state: Such a state occur when the system can allocate resources to each
process (up to its maximum) in some order and avoid a deadlock. This state will
be characterised by a safe sequence. It must be mentioned here that we should
not falsely conclude that all unsafe states are deadlocked although it may eventually
lead to a deadlock.
 Unsafe State: If the system did not follow the safe sequence of resource allocation
from the beginning and it is now in a situation, which may lead to a deadlock, then
it is in an unsafe state.
 Deadlock State: If the system has some circular wait condition existing for some
processes, then it is in deadlock state.
Let us study this concept with the help of an example as shown below:
Consider an analogy in which 4 processes (P1, P2, P3 and P4) can be compared with
the customers in a bank, resources such as printers etc. as cash available in the bank
and the Operating system as the Banker.
Table 2
Processes Resources Maximum
used resources
P1 0 6
P2 0 5
P3 0 4
P4 0 7

Let us assume that total available resources = 10

In the above table, we see four processes, each of which has been granted a number of
maximum resources that can be used. The Operating system reserved only 10 resources
rather than 22 units to service them.At a certain moment, the situation becomes:
Table 3
Processes Resources Maximum
used resources
P1 1 6
P2 1 5
P3 2 4
P4 4 7
Available resources = 2 89
Introduction to Operating Safe State: The key to a state being safe is that there is at least one way for all users
Systems and Process
Management to finish. In other words the state of Table 2 is safe because with 2 units left, the
operating system can delay any request except P3, thus letting P3 finish and release all
four resources. With four units in hand, the Operating system can let either P4 or P2
have the necessary units and so on.
Unsafe State: Consider what would happen if a request from P2 for one more unit
was granted in Table 3. We would have following situation as shown in Table 4.
Table 4
Processes Resources Maximum
used resources
P1 1 6
P2 2 5
P3 2 4
P4 4 7

Available resource = 1
This is an unsafe state.
If all the processes request for their maximum resources respectively, then the operating
system could not satisfy any of them and we would have a deadlock.
Important Note: It is important to note that an unsafe state does not imply the existence
or even the eventual existence of a deadlock. What an unsafe state does imply is
simply that some unfortunate sequence of events might lead to a deadlock.
The Banker’s algorithm is thus used to consider each request as it occurs, and see if
granting it leads to a safe state. If it does, the request is granted, otherwise, it is postponed
until later. Haberman [1969] has shown that executing of the algorithm has a complexity
proportional to N2 where N is the number of processes and since the algorithm is
executed each time a resource request occurs, the overhead is significant.
Limitations of the Banker’s Algorithm
There are some problems with the Banker’s algorithm as given below:
 It is time consuming to execute on the operation of every resource.
 If the claim information is not accurate, system resources may be underutilized.
 Another difficulty can occur when a system is heavily loaded. Lauesen states that
in this situation “so many resources are granted away that very few safe sequences
remain, and as a consequence, the jobs will be executed sequentially”. Therefore,
the Banker’s algorithm is referred to as the “Most Liberal” granting policy; that is,
it gives away everything that it can without regard to the consequences.
 New processes arriving may cause a problem.
– The process’s claim must be less than the total number of units of the resource
in the system. If not, the process is not accepted by the manager.
90
 – Since the state without the new process is safe, so is the state with the new Deadlocks
process. Just use the order you had originally and put the new process at the
end.
– Ensuring fairness (starvation freedom) needs a little more work, but isn’t too
hard either (once every hour stop taking new processes until all current
processes finish).
 A resource becoming unavailable (e.g., a tape drive breaking), can result in an
unsafe state.

4.5.3 Deadlock Detection and Recovery

Detection of deadlocks is the most practical policy, which being both liberal and cost
efficient, most operating systems deploy. To detect a deadlock, we must go about in a
recursive manner and simulate the most favoured execution of each unblocked process.
 An unblocked process may acquire all the needed resources and will execute.
 It will then release all the acquired resources and remain dormant thereafter.
 The now released resources may wake up some previously blocked process.
 Continue the above steps as long as possible.
 If any blocked processes remain, they are deadlocked.
Recovery from Deadlock
Recovery by process termination
In this approach we terminate deadlocked processes in a systematic way taking into
account their priorities. The moment, enough processes are terminated to recover
from deadlock, we stop the process terminations. Though the policy is simple, there
are some problems associated with it.
Consider the scenario where a process is in the state of updating a data file and it is
terminated. The file may be left in an incorrect state by the unexpected termination of
the updating process. Further, processes should be terminated based on some criterion/
policy. Some of the criteria may be as follows:
 Priority of a process
 CPU time used and expected usage before completion
 Number and type of resources being used (can they be preempted easily?)
 Number of resources needed for completion
 Number of processes needed to be terminated
 Are the processes interactive or batch?
Recovery by Checkpointing and Rollback (Resource preemption)
Some systems facilitate deadlock recovery by implementing checkpointing and
rollback. Checkpointing is saving enough state of a process so that the process can
be restarted at the point in the computation where the checkpoint was taken.Autosaving
file edits are a form of checkpointing. Checkpointing costs depend on the underlying 91
Introduction to Operating algorithm. Very simple algorithms (like linear primality testing) can be checkpointed
Systems and Process
Management with a few words of data. More complicated processes may have to save all the
process state and memory.
If a deadlock is detected, one or more processes are restarted from their last checkpoint.
Restarting a process from a checkpoint is called rollback. It is done with the expectation
that the resource requests will not interleave again to produce deadlock.
Deadlock recovery is generally used when deadlocks are rare, and the cost of recovery
(process termination or rollback) is low.
Process checkpointing can also be used to improve reliability (long running
computations), assist in process migration, or reduce startup costs.


Check Your Progress 1
1) What is a deadlock and what are the four conditions that will create the deadlock
situation?
........................................................................................................................
........................................................................................................................
........................................................................................................................
........................................................................................................................

2) How can deadlock be avoided? Explain with the help of an example.

........................................................................................................................
........................................................................................................................
........................................................................................................................
........................................................................................................................

4.6 SUMMARY
A deadlock occurs a process has some resource and is waiting to acquire another
resource, while that resource is being held by some process that is waiting to acquire
the resource that is being held by the first process.
A deadlock needs four conditions to occur: Mutual Exclusion, Hold and Wait, Non-
Preemption and Circular Waiting.
We can handle deadlocks in three major ways: We can prevent them, handle them
when we detect them, or simply ignore the whole deadlock issue altogether.

4.7 SOLUTIONS/ANSWERS
Check Your Progress 1
1) A set of processes is in a deadlock state when every process in the set is waiting
for an event that can only be caused by another process in the set. A deadlock
situation can arise if the following four conditions hold simultaneously in a system:
92
  Mutual Exclusion: At least one resource must be held in a non-shareable Deadlocks

mode; that is, only one process at a time can use the resource. If another
process requests the resource, the requesting process must be delayed until
the resource has been released.

 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.

 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.

 Circular Wait: A set {P0, P1, P2, …, Pn} of waiting processes must exist
such that P0 is waiting for a resource that is held by P1, P1 is waiting for a
resource that is held by P2, …, Pn-1 is waiting for a resource that is held by
Pn, and Pn is waiting for a resource that is held by P0.

2) Deadlock avoidance deals with processes that declare before execution how many
resources they may need during their execution. Given several processes and
resources, if we can allocate the resources in some order as to prevent a deadlock,
the system is said to be in a safe state. If a deadlock is possible, the system is said
to be in an unsafe state. The idea of avoiding a deadlock is to simply not allow the
system to enter an unsafe state which may cause a deadlock. We can define what
makes an unsafe state.

For example, consider a system with 12 tape drives and three processes: P0, P1
and P2. P0 may require 10 tape drives during execution, P1 may require 4, and
P2 may require up to 9. Suppose that at some moment in time, P0 is holding on to
5 tape drives, P1 holds 2 and P2 holds 2 tape drives. The system is said to be in
a safe state, since there is a safe sequence that avoids the deadlock. This sequence
implies that P1 can instantly get all of its needed resources (there are 12 total tape
drives, and P1 already has 2, so the maximum it needs is 2, which it can get since
there are 3 free tape drives). Once it finishes executing, it releases all 4 resources,
which makes for 5 free tape drives, at which point, P0 can execute (since the
maximum it needs is 10), after it finishes, P2 can proceed since the maximum it
needs is 9.

Now, here’s an unsafe sequence: Let’s say at some point of time P2 requests one
more resource to make its holding resources 3. Now the system is in an unsafe
state, since only P1 can be allocated resources, and after it returns, it will only
leave 4 free resources, which is not enough for either P0 or P2, so the system
enters a deadlock.

4.8 FURTHER READINGS

1) Madnick and Donovan, Operating systems – Concepts and Design, McGrawHill
Intl. Education.
2) Milan Milenkovic, Operating Systems, Concepts and Design, TMGH, 2000.
93
Introduction to Operating 3) D.M. Dhamdhere, Operating Systems, A concept-based approach, TMGH,
Systems and Process
Management 2002.
4) Abraham Silberschatz and James L, Operating System Concepts.
Peterson,Addition Wesely Publishing Company, New Delhi.
5) Harvay M. Deital, Introduction to Operating systems,Addition Wesely Publishing
Company, New Delhi.
6) Andrew S. Tanenbaum, Operating System Design and Implementation, PHI,
New Delhi.

94