UNIT II NOTES

UNIT II PROCESS MANAGEMENT

Processes - Process Concept, Process Scheduling, Operations on Processes, Inter-process

Communication; CPU Scheduling - Scheduling criteria, Scheduling algorithms, Threads-
Overview, Multithreading models, Threading issues; Process Synchronization - The critical-
section problem, Synchronization hardware, Semaphores, Mutex, Classic problems of
synchronization, Monitors; Deadlock - Methods for handling deadlocks, Deadlock prevention,
Deadlock avoidance, Deadlock detection, Recovery from deadlock.

Sl.no Table of contents Page number

1. Processes 3
a. Process Concept 3
b. Process Scheduling 8
c. Operations on Processes 12
d. Interprocess Communication 17
2. Threads 22
a. Overview 22
b. Multithreading Models 25
c. Threading issues 27
3. Process Synchronization 30
a. Critical Section Problem 30
b. Synchronization hardware 32
c. Mutex Locks 33
d. Semophores 34
e. Classic problems of synchronization 39
f. Monitors 43
4. CPU Scheduling 49
a. Basic concepts 49
b. Scheduling criteria 50
c. Scheduling algorithms 51
1. FCFS Scheduling 51
2. SJF Scheduling 52
3. Priority Scheduling 52
4. Round-Robin Scheduling 52
5. Multilevel Queue Scheduling 53
6. Multilevel Feedback Queue Scheduling 54
5. Deadlocks 55

1
UNIT II NOTES

a. Definition of Deadlocks 55
b. Deadlock Characterization 55
c. Methods for Handling Deadlocks 59
d. Deadlock Prevention 59
e. Deadlock Avoidance 61
f. Deadlock Detection 66
g. Recovery from Deadlock 69

2
UNIT II NOTES

Processes
➢ Process Concept
➢ Process Scheduling
➢ Operations on Processes
➢ Interprocess Communication

Process Concept
1. The Process
2. Process states
3. Process control block
4. Threads

1. The Process:
✓ Program:
o Set of instructions is known as program.
✓ Process:
o A program in execution is known as process.

✓ Structure of a process:
o The structure of a process in memory is shown in Figure 3.1.
o It includes,
▪ Text section
▪ Stack
▪ Data section
▪ Heap

❖ Text section:
o It includes the current activity, as represented by the value of the program
counter and the contents of the processor’s registers.
❖ Stack:
o It contains temporary data such as,
▪ Function parameters
▪ return addresses, and
▪ local variables
❖ Data section:
o It contains global variables.
❖ Heap:
o It contains the memory that is dynamically allocated during process run time.
3
UNIT II NOTES

Sl.no Program Process

1. Set of instructions is known as A program in execution is known
program. as process.

2. A program is a passive entity, A process is an active entity, with

such as a file containing a list of a program counter specifying the
instructions stored on disk. next instruction to execute and a
set of associated resources.

2. Process states:
✓ It is defined in part by the current activity of that process.
✓ As a process executes, it changes the state.
✓ 5 states:
1. New
2. Running
3. Waiting
4. Ready
5. Terminated

o New:
- The process is being created.

o Running:
- Instructions are being executed.
4
UNIT II NOTES

o Waiting:
- The process is waiting for some event to occur.

o Ready:
- The process is waiting to be assigned to a processor.

o Terminated:
- The process has finished execution.

3. Process control block:

✓ Each process is represented in the operating system by a process control block (PCB).
✓ Also called a task control block.
✓ A PCB is shown in Figure 3.3.

5
UNIT II NOTES

✓ it contains many pieces of information associated with a process such as,

o Process state
o Program counter
o CPU registers
o CPU-scheduling information
o Memory-management information
o Accounting information
o I/O status information

❖ Process state:
o The state may be new, ready, running, and waiting, halted, and so on.

❖ Program counter:
o Indicates the address of the next instruction to be executed for this process.

❖ CPU registers:
o The registers vary in number and type, depending on the computer architecture.
o They include,
▪ Accumulators
▪ index registers
▪ stack pointers
▪ general-purpose registers
▪ any condition-code information.

❖ CPU-scheduling information:
o This information includes,
▪ a process priority
▪ pointers to scheduling queues
▪ any other scheduling parameters.

❖ Memory-management information:
o This information may include,
▪ base register value
▪ limit register value
▪ page tables
▪ segment tables.

❖ Accounting information:
o This information includes,
6
UNIT II NOTES

▪ amount of CPU
▪ Amount of real time used
▪ time limits
▪ account numbers
▪ job or process numbers

❖ I/O status information:

o This information includes,
▪ the list of I/O devices allocated to the process,
▪ a list of open files

4. Threads:
✓ A thread is a basic unit of CPU utilization.
✓ it comprises,
a. thread ID
b. a program counter
c. a register set
d. a stack
✓ Most modern operating systems have extended the process concept to allow a process to
have multiple threads of execution and thus to perform more than one task at a time.

7
UNIT II NOTES

Process Scheduling
✓ Process scheduler selects an available process for program execution on the CPU.

❖ Scheduling Queues
❖ Schedulers
❖ Context Switch

❖ Scheduling Queues:
o Job queue:
▪ Job queue consists of all processes in the system.

o Ready queue:
▪ The processes that are residing in main memory and are ready and waiting
to execute are kept on a list called the ready queue.
▪ This queue is generally stored as a linked list.

o Device queue:
▪ The list of processes waiting for a particular I/O device is called a device
queue.
▪ Each device has its own device queue.

8
UNIT II NOTES

o Queuing diagram:
▪ A common representation of process scheduling is a queueing diagram,
such as that in Figure 3.6.
▪ Each rectangular box represents a queue.
▪ Two types of queues are present:
a. the ready queue
b. a set of device queues.
▪ The circles represent the resources that serve the queues.
▪ The arrows indicate the flow of processes in the system.
▪ Working of queuing diagram:
• A new process is initially put in the ready queue.
• It waits there until it is selected for execution, or dispatched.
• Once the process is allocated the CPU and is executing, one of
several events could occur:
• The process could issue an I/O request and then be placed in an I/O
queue.
• The process could create a new child process and wait for the
child’s termination.
• The process could be removed forcibly from the CPU, as a result
of an interrupt, and be put back in the ready queue.

❖ Schedulers:
o The operating system must select, for scheduling purposes, processes from these
queues in some fashion.
o The selection process is carried out by the appropriate scheduler.
o The long-term scheduler controls the degree of multiprogramming (the number
of processes in memory).
o 3 types of schedulers:
▪ Long-term scheduler
▪ Short-term scheduler
▪ Medium term scheduler:
• This medium-term scheduler is diagrammed in Figure 3.7.
• The key idea behind a medium-term scheduler is that sometimes it
can be advantageous to remove a process from memory and thus
reduce the degree of multiprogramming.
• Later, the process can be reintroduced into memory, and its
execution can be continued where it left off. This scheme is called
swapping.

9
UNIT II NOTES

• The process is swapped out, and is later swapped in, by the

medium-term scheduler.

Job scheduler CPU scheduler

1. Also known as long-term scheduler. Also known as short-term scheduler.

2. Selects processes from job pool and Selects from among the processes that are
loads them into memory for execution. ready to execute and allocates the CPU to
one of them.

3. The long-term scheduler executes The short-term scheduler must select a new
much less frequently. process for the CPU more frequently.

4. Because of the longer interval between Because of the short time between
executions, long-term scheduler will executions, the short-term scheduler must
be slow. be fast.

o 2 categories of processes:
▪ I/O-bound process
▪ CPU-bound process
o An I/O-bound process is one that spends more of its time doing I/O than it spends doing
computations.
o A CPU-bound process, in contrast, generates I/O requests infrequently, using more of its
time doing computations.

10
UNIT II NOTES

o It is important that the long-term scheduler select a good process mix of I/O-bound and
CPU-bound processes.

❖ Context Switch:
o When an interrupt occurs, the system needs to save the current context of the
process running on the CPU so that it can restore that context when its processing
is done, essentially suspending the process and then resuming it.
o The context is represented in the PCB of the process.
o It includes the value of the CPU registers, the process state, and memory-
management information.
o Switching the CPU to another process requires performing a state save of the
current process and a state restore of a different process. This task is known as a
context switch.
o When a context switch occurs, the kernel saves the context of the old process in
its PCB and loads the saved context of the new process scheduled to run.
o Context-switch times are highly dependent on hardware support.

11
UNIT II NOTES

Operations on processes
1. Process creation
2. Process termination

1. Process creation:
➢ During the course of execution, a process may create several new processes.
➢ The creating process is called a parent process, and the new processes are called the
children of that process.
➢ Each of these new processes may in turn create other processes, forming a tree of
processes.
➢ Most operating systems (including UNIX, Linux, and Windows) identify processes
according to a unique process identifier (or pid), which is typically an integer
number.
➢ The pid provides a unique value for each process in the system.

➢ Figure 3.8 illustrates a typical process tree for the Linux operating system, showing
the name of each process and its pid.
➢ The init process (which always has a pid of 1) serves as the root parent process for all
user processes.
➢ Once the system has booted, the init process can also create various user processes,
such as a web or print server, an ssh server, and the like.
➢ When a process creates a child process, that child process will need certain resources
such as,
a. CPU time
b. Memory

12
UNIT II NOTES

c. Files
d. I/O devices
to accomplish its task.
➢ A child process may be able to obtain its resources,
a. directly from the operating system
b. may be constrained to a subset of the resources of the parent process.
➢ Parent process supplies the following resources to the child processes,
o physical resources
o logical resources
o data input

➢ When a process creates a new process, two possibilities for execution exist:
1. The parent continues to execute concurrently with its children.
2. The parent waits until some or all of its children have terminated.

➢ There are also two address-space possibilities for the new process:
1. The child process is a duplicate of the parent process (it has the same program and
data as the parent).
2. The child process has a new program loaded into it.

➢ A new process is created by the fork( ) system call.

➢ The new process consists of a copy of the address space of the original process.
➢ After a fork( ) system call, one of the two processes typically uses the exec( ) system
call to replace the process’s memory space with a new program.
➢ The exec( ) system call loads a binary file into memory and starts its execution.
➢ The parent can then create more children; or, if it has nothing else to do while the
child runs, it can issue a wait( ) system call to move itself off the ready queue until
the termination of the child.

13
UNIT II NOTES

➢ Example routine: Creating a separate process using UNIX fork( ) system call
#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>
int main()
{
pid t pid;
/* fork a child process */
pid = fork();
if (pid < 0)
{ /* error occurred */
fprintf(stderr, "Fork Failed");
return 1;
}
else if (pid == 0)
{ /* child process */
execlp("/bin/ls","ls",NULL);
}
else
{ /* parent process */
/* parent will wait for the child to complete */
wait(NULL);
printf("Child Complete");
}
return 0;
}

2. Process termination:
➢ A process terminates when it finishes executing its final statement and asks the operating
system to delete it by using the exit( ) system call.
➢ At that point, the process may return a status value (typically an integer) to its parent
process (via the wait( ) system call).
➢ All the resources of the process—including physical and virtual memory, open files, and
I/O buffers—are deallocated by the operating system.
➢ A parent may terminate the execution of one of its children for a variety of reasons, such
as these:
1. The child has exceeded its usage of some of the resources that it has been allocated.
2. The task assigned to the child is no longer required.

14
UNIT II NOTES

3. The parent is exiting, and the operating system does not allow a child to continue if
its parent terminates.
➢ Cascading termination:
o If a process terminates (either normally or abnormally), then all its children must
also be terminated. This phenomenon, referred to as cascading termination.
➢ To illustrate process execution and termination, consider that, in Linux and UNIX
systems, we can terminate a process by using the exit( ) system call, providing an exit
status as a parameter:
/* exit with status 1 */
exit(1);
➢ A parent process may wait for the termination of a child process by using the wait( )
system call.
➢ The wait( ) system call is passed a parameter that allows the parent to obtain the exit
status of the child.
➢ This system call also returns the process identifier of the terminated child so that the
parent can tell which of its children has terminated:
pid _t pid;
int status;
pid = wait(&status);
➢ A process that has terminated, but whose parent has not yet called wait( ), is known as a
zombie process.

15
UNIT II NOTES

Interprocess Communication
✓ 2 types of processes:
a. independent processes
b. cooperating processes

Independent processes Cooperating processes

1. A process is independent if it cannot 1. A process is cooperating if it can
affect or be affected by the other affect or be affected by the other
processes executing in the system. processes executing in the system.

2. Does not share data with any other 2. Shares data with other processes.
processes.

✓ The reasons for providing an environment that allows process cooperation:

1) information sharing
2) computation speedup
3) modularity
4) convenience

➢ Information sharing:
o We must provide an environment to allow concurrent access to such
information.

➢ Computation speedup:
o If we want a particular task to run faster, we must break it into subtasks,
each of which will be executing in parallel with the others.

➢ modularity:
o We may want to construct the system in a modular fashion, dividing the
system functions into separate processes or threads.

➢ Convenience:
o Even an individual user may work on many tasks at the same time.
o For instance, a user may be editing, listening to music, and compiling in
parallel.

❖ Shared memory systems

❖ Message passing systems

16
UNIT II NOTES

❖ Shared memory systems:

o In the shared-memory model, a region of memory that is shared by cooperating
processes is established.
o Processes can then exchange information by reading and writing data to the
shared region.
o Interprocess communication using shared memory requires communicating
processes to establish a region of shared memory.
o A shared-memory region resides in the address space of the process creating the
shared-memory segment.
o Other processes that wish to communicate using this shared-memory segment
must attach it to their address space.

▪ Producer Consumer problem:

o A producer process produces information that is consumed by a consumer
process.
o The producer's job is to generate a piece of data, put it into the buffer and start
again.
o At the same time, the consumer is consuming the data (i.e., removing it from the
buffer) one piece at a time.
o The problem is to make sure that the producer won't try to add data into the buffer
if it's full and that the consumer won't try to remove data from an empty buffer.

17
UNIT II NOTES

o One solution to the producer–consumer problem uses shared memory.

o To allow producer and consumer processes to run concurrently, we must have
available a buffer of items that can be filled by the producer and emptied by the
consumer.
o This buffer will reside in a region of memory that is shared by the producer and
consumer processes.
o A producer can produce one item while the consumer is consuming another item.
o The producer and consumer must be synchronized, so that the consumer does not
try to consume an item that has not yet been produced.
o 2 types of buffers can be used.
▪ unbounded buffer
▪ bounded buffer

unbounded buffer bounded buffer

1. Size of the buffer is not limited. Fixed. buffer size

2. The consumer may have to wait for new The consumer must wait if the buffer is
items, but the producer can always produce empty, and the producer must wait if the
new items. buffer is full.

❖ Message passing systems:

o Message passing provides a mechanism to allow processes to communicate and to
synchronize their actions without sharing the same address space.
o It is particularly useful in a distributed environment, where the communicating
processes may reside on different computers connected by a network.
o Provides two operations,
▪ Send(message)
▪ Receive(message)
✓ Message exchanged can be either,
i. Fixed size
ii. Variable size.
✓ If processes P and Q want to communicate, they must send messages to and
receive messages from each other: a communication link must exist between
them.
✓ Methods for logically implementing a link and the send( )/receive( ) operations are,
i. Direct or indirect communication

18
UNIT II NOTES

ii. Synchronous or asynchronous communication

iii. Automatic or explicit buffering

➢ Naming
➢ Synchronization
➢ Buffering

➢ Naming:
✓ Process that want to communicate have a way to refer each other.
✓ Communication may be,
▪ Direct communication
▪ Indirect communication
✓ Direct Communication:
o Each process that wants to communicate must name the recipient or sender of
the communication.
o 2 categories of addressing:
1. Symmetry
2. Asymmetry
Symmetry:
o Both the sender process and the receiver process must name the other to
communicate.
o Send and receive primitives are defined as,
▪ Send( P, message ) → send message to process P
▪ Receive( Q, message ) → Receive a message from process Q

o A communication link in this scheme has the following properties:

▪ A link is established automatically between every pair of processes
that want to communicate. The processes need to know only each
other’s identity to communicate.
▪ A link is associated with exactly two processes.
▪ Between each pair of processes, there exists exactly one link.

Asymmetry:
o Only the sender names the recipient; the recipient is not required to name the
sender.
o Send and receive primitives are defined as,
▪ Send ( P, message ) → Send a message to process P.

19
UNIT II NOTES

▪ Receive ( id, message ) → Receive a message from any process. The

variable id is set to the name of the process with which communication
has taken place.

✓ Indirect Communication:
o Messages are sent and received via mailbox or ports.
o Send and receive Primitive defined as,
▪ Send ( A, message ) → send message to mail box A
▪ Receive ( A, message ) → Receive a message from mail box A.
o In this scheme, a communication link has the following properties:
▪ A link is established between a pair of processes only if both members
of the pair have a shared mailbox.
▪ A link may be associated with more than two processes.
▪ Between each pair of communicating processes, a number of different
links may exist, with each link corresponding to one mailbox.

➢ Synchronization:
✓ Communication between processes takes place through calls to send( ) and
receive( ) primitives.
✓ Message passing may be either blocking or nonblocking— also known as
synchronous and asynchronous.

✓ Blocking send
✓ Nonblocking send
✓ Blocking receive
✓ Nonblocking receive

✓ Blocking send:
▪ The sending process is blocked until the message is received by the
receiving process or by the mailbox.

✓ Nonblocking send:
▪ The sending process sends the message and resumes operation.

✓ Blocking receive:
▪ The receiver blocks until a message is available.

✓ Nonblocking receive:
▪ The receiver retrieves either a valid message or a null.
20
UNIT II NOTES

➢ Buffering:
✓ Whether communication is direct or indirect, messages exchanged by
communicating processes reside in a temporary queue.
✓ Basically, such queues can be implemented in three ways:
1. Zero capacity
2. Bounded capacity
3. Unbounded capacity
✓ The zero-capacity case is sometimes referred to as a message system with no
buffering.
✓ The other cases are referred to as systems with automatic buffering.

Zero capacity:
- The queue has a maximum length of zero.
- The link cannot have any messages waiting in it.
- The sender must block until the recipient receives the message.

Bounded capacity:
- The queue has finite length n.
- If the queue is not full when a new message is sent, the message is placed in the
queue, and the sender can continue execution without waiting.

Unbounded capacity:
- The queue’s length is infinite.
- Any number of messages can wait in it.
- The sender never blocks.

21
UNIT II NOTES

Threads
➢ Overview
➢ Multithreading Models
➢ Threading issues

Overview
✓ Definition of thread
✓ Motivation
✓ Benefits

❖ Definition of thread:
o A thread is a basic unit of CPU utilization.
o It comprises,
a. thread ID
b. a program counter
c. a register set
d. a stack
Difference between Process and Thread
Process Thread
Process is heavy weight or resource Thread is light weight taking lesser resources
intensive. than a process.
Process switching needs interaction with Thread switching does not need to interact with
operating system. operating system.
In multiple processing environments each All threads can share same set of open files,
process executes the same code but has its child processes.
own memory and file resources.
If one process is blocked then no other While one thread is blocked and waiting, second
process can execute until the first process is thread in the same task can run.
unblocked.
Multiple processes without using threads use Multiple threaded processes use fewer
more resources. resources.
In multiple processes each process operates One thread can read, write or change another
independently of the others. thread's data.
❖ Motivation:
o Types of Thread:
i. User Level Threads -- User managed threads
ii. Kernel Level Threads -- Operating System managed threads acting on
kernel, an operating system core.
22
UNIT II NOTES

o Figure 4.1 illustrates the difference between a traditional single-threaded process and
a multithreaded process.
o Examples of multithreaded process:
i. A web browser might have one thread display images or text while another
thread retrieves data from the network.
ii. A word processor may have a thread for displaying graphics, another thread
for responding to keystrokes from the user, and a third thread for performing spelling
and grammar checking in the background.

❖ Benefits:
o Responsiveness
o Resource sharing
o Economy
o Scalability
✓ Responsiveness:
- Allows a program to continue running even if part of it is blocked thereby increasing
the responsiveness.

✓ Resource sharing:
- Processes can only share resources through techniques such as,
o shared memory
o message passing
23
UNIT II NOTES

✓ Economy:
- Threads share the resources of the process to which they belong, it is more
economical to create and context-switch threads.

✓ Scalability:
- The benefits of multithreading can be even greater in a multiprocessor architecture,
where threads may be running in parallel on different processing cores.

24
UNIT II NOTES

Multithreading Models

o Types of Thread:
i. User Level Threads -- User managed threads
ii. Kernel Level Threads -- Operating System managed threads acting on
kernel, an operating system core.
o 3 common ways of establishing relationship:
✓ Many-to-One
✓ One-to-One
✓ Many-to-Many

➢ Many-to-One:
o The many-to-one model (Figure 4.5) maps many user-level threads to one
kernel thread.
o Merit:
▪ Thread management is done by the thread library in user space, so it is
efficient.
o Demerit:
▪ The entire process will block if a thread makes a blocking system call.
▪ Multiple threads are unable to run in parallel on multicore systems
because only one thread can access the kernel at a time.

➢ One-to-One:
o The one-to-one model (Figure 4.6) maps each user thread to a kernel thread.
25
UNIT II NOTES

o Merit:
▪ It provides more concurrency than the many-to-one model by allowing
another thread to run when a thread makes a blocking system call.
▪ It also allows multiple threads to run in parallel on multiprocessors.
o Demerit:
▪ Creating a user thread requires creating the corresponding kernel
thread.

➢ Many-to-Many:
o The many-to-many model (Figure 4.7) multiplexes many user-level threads to
a smaller or equal number of kernel threads.
o Merit:
▪ Developers can create as many user threads as necessary, and the
corresponding kernel threads can run in parallel on a multiprocessor.
▪ When a thread performs a blocking system call, the kernel can
schedule another thread for execution.

26
UNIT II NOTES

Threading issues
• The fork() and exec() system calls
• Signal handling
• Thread cancellation
• Thread local storage

• The fork() and exec() System Calls:

o The semantics of the fork() and exec() system calls change in a multithreaded
program.
o Some UNIX systems have chosen to have two versions of fork(),
▪ one that duplicates all threads and
▪ another that duplicates only the thread that invoked the fork() system call.
o The exec() system call typically works in the same way. That is, if a thread
invokes the exec() system call, the program specified in the parameter to exec()
will replace the entire process—including all threads.

• Signal handling:
o A signal is used in UNIX systems to notify a process that a particular event has
occurred.
o A signal may be received either synchronously or asynchronously, depending on
the source of and the reason for the event being signaled.
o All signals, whether synchronous or asynchronous, follow the same pattern:
1. A signal is generated by the occurrence of a particular event.
2. The signal is delivered to a process.
3. Once delivered, the signal must be handled.
o Synchronous signals are delivered to the same process that performed the
operation that caused the signal (that is the reason they are considered
synchronous).
o When a signal is generated by an event external to a running process, that process
receives the signal asynchronously.
o Examples of such signals include terminating a process with specific keystrokes
(such as <control><C>) and having a timer expire.
o Typically, an asynchronous signal is sent to another process.
o A signal may be handled by one of two possible handlers:
1. A default signal handler
2. A user-defined signal handler
o Every signal has a default signal handler that the kernel runs when handling that
signal.
27
UNIT II NOTES

o This default action can be overridden by a user-defined signal handler that is

called to handle the signal.
o Signals are handled indifferent ways. Some signals (such as changing the size of a
window) are simply ignored; others (such as an illegal memory access) are
handled by terminating the program.
o The standard UNIX function for delivering a signal is
kill(pid t pid, int signal)
o This function specifies the process (pid) to which a particular signal (signal) is to
be delivered.
o Most multithreaded versions of UNIX allow a thread to specify which signals it
will accept and which it will block.

• Thread cancellation:
o Thread cancellation involves terminating a thread before it has completed.
o For example, if multiple threads are concurrently searching through a database
and one thread returns the result, the remaining threads might be canceled.
o Another situation might occur when a user presses a button on a web browser that
stops a web page from loading any further.
o Often, a web page loads using several threads—each image is loaded in a separate
thread.
o When a user presses the stop button on the browser, all threads loading the page
are canceled.
o A thread that is to be canceled is often referred to as the target thread.
o Cancellation of a target thread may occur in two different scenarios:
1. Asynchronous cancellation. One thread immediately terminates the target
thread.
2. Deferred cancellation. The target thread periodically checks whether it should
terminate, allowing it an opportunity to terminate itself in an orderly fashion.
o In Pthreads, thread cancellation is initiated using the pthread cancel() function.
o The identifier of the target thread is passed as a parameter to the function. The
following code illustrates creating—and then canceling— a thread:

28
UNIT II NOTES

o The default cancellation type is deferred cancellation.

o Here, cancellation occurs only when a thread reaches a cancellation point. One
technique for establishing a cancellation point is to invoke the
pthread_testcancel() function.
o If a cancellation request is found to be pending, a function known as a cleanup
handler is invoked.
o This function allows any resources a thread may have acquired to be released
before the thread is terminated.

• Thread local storage:

o Threads belonging to a process share the data of the process.
o Indeed, this data sharing provides one of the benefits of multithreaded
programming.
o However, in some circumstances, each thread might need its own copy of certain
data. We will call such data thread-local storage (or TLS.)
o TLS is similar to static data. The difference is that TLS data are unique to each
thread.

29
UNIT II NOTES

Process Synchronization
➢ Critical Section Problem
➢ Synchronization hardware
➢ Mutex Locks
➢ Semophores
➢ Classic problems of synchronization
➢ Monitors

Critical Section Problem

✓ Consider a system consisting of n processes {P0, P1, ..., Pn−1}.
✓ Critical section :
o Each process has a segment of code, called a critical section, in which the process
may be changing common variables, updating a table, writing a file, and so on.
✓ Critical-section problem:
o When one process is executing in its critical section, no other process is allowed
to execute in its critical section.
o The critical-section problem is to design a protocol that the processes can use to
cooperate.
✓ 2 sections:
o entry section
o section
✓ Entry section:
o Each process must request permission to enter its critical section.
o The section of code implementing this request is the entry section.
✓ Exit section:
o The critical section may be followed by an exit section.
o The remaining code is the remainder section.
✓ The general structure of a typical process Pi is shown in Figure 5.1.

✓ A solution to the critical-section problem must satisfy the following three requirements

30
UNIT II NOTES

1. Mutual exclusion
2. Progress
3. Bounded waiting

Mutual exclusion:
- If process Pi is executing in its critical section, then no other processes can be
executing in their critical sections.

Progress:
- No process is executing in its critical section.
- Some processes wish to enter their critical sections.
- Only those processes that are not executing in their remainder sections can participate
in deciding which will enter its critical section next.

Bounded waiting:
- There exists a bound, or limit, on the number of times that other processes are
allowed to enter their critical sections.

✓ Race condition:
o A situation where several processes access and manipulate the same data
concurrently and the outcome of the execution depends on the particular order in
which the access takes place, is called a race condition.
✓ Two general approaches are used to handle critical sections in operating systems:
o preemptive kernels
o non-preemptive kernels

Preemptive kernels Non-preemptive kernels

✓ A preemptive kernel allows a process ✓ A nonpreemptive kernel does not

to be preempted while it is running in allow a process running in kernel
kernel mode. mode to be pre-empted.

31
UNIT II NOTES

Synchronization hardware
• The critical-section problem could be solved simply in a single-processor environment if
we could prevent interrupts from occurring while a shared variable was being modified.
• In this way, we could be sure that the current sequence of instructions would be allowed
to execute in order without preemption.
• No other instructions would be run, so no unexpected modifications could be made to the
shared variable.
• This is often the approach taken by nonpreemptive kernels.
• Unfortunately, this solution is not as feasible in a multiprocessor environment.
• Disabling interrupts on a multiprocessor can be time consuming, since the message is
passed to all the processors.
• This message passing delays entry into each critical section, and system efficiency
decreases.
• The test and set() instruction can be defined as shown in Figure 5.3.
• The important characteristic of this instruction is that it is executed atomically.
• Thus, if two test and set() instructions are executed simultaneously (each on a different
CPU), they will be executed sequentially in some arbitrary order.
• If the machine supports the test and set() instruction, then we can implement mutual
exclusion by declaring a boolean variable lock, initialized to false.
• The structure of process Pi is shown in Figure 5.4.

32
UNIT II NOTES

Mutex Locks

✓ Operating-systems designers build software tools to solve the critical-section problem.

✓ The simplest of these tools is the mutex lock. (In fact, the term mutex is short for mutual
exclusion.)
✓ We use the mutex lock to protect critical regions and thus prevent race conditions.
✓ That is, a process must acquire the lock before entering a critical section; it releases the
lock when it exits the critical section.
✓ 2 functions:
1. acquire( )
2. release( )
✓ The acquire( )function acquires the lock.
✓ The release( ) function releases the lock, as illustrated in Figure 5.8.

✓ A mutex lock has a boolean variable available whose value indicates if the lock is
available or not.
✓ The definition of acquire( ) is as follows:
acquire( )
{
while (!available)
; /* busy wait */
available = false;;
}
✓ The definition of release( ) is as follows:
release( )
{

33
UNIT II NOTES

available = true;
}
✓ Disadvantage of mutex locks:
o It requires busy waiting.
✓ While a process is in its critical section, any other process that tries to enter its critical
section must loop continuously in the call to acquire( ).
✓ In fact, this type of mutex lock is also called a spinlock.
✓ Demerit of busy waiting:
o Busy waiting wastes CPU cycles that some other process might be able to use
productively.
✓ Advantages of spinlocks:
o No context switch is required when a process must wait on a lock, and a context
switch may take considerable time.

34
UNIT II NOTES

Semophores

✓ A semaphore S is an integer variable that, apart from initialization, is accessed only

through two standard atomic operations:
o wait( )
o signal( )
✓ The wait( ) operation was originally termed P (from the Dutch proberen, “to test”);
✓ signal( ) was originally called V (from verhogen, “to increment”).
✓ The definition of wait( ) is as follows:
wait(S)
{
while (S <= 0)
; // busy wait
S--;
}
o The definition of signal( ) is as follows:
signal(S)
{
S++;
}

➢ Semaphore usage
➢ Semaphore implementation
➢ Deadlocks & starvation
➢ Priority inversion

➢ Semaphore usage:
o 2 types of semaphores,
▪ Counting semaphore
▪ Binary semaphore

Counting semaphore Binary semaphore

The value of a counting semaphore can The value of a binary semaphore can
range over an unrestricted domain. range only between 0 and 1.

Thus, binary semaphores behave

similarly to mutex locks.

35
UNIT II NOTES

o Counting semaphores can be used to control access to a given resource consisting

of a finite number of instances.
o The semaphore is initialized to the number of resources available.
o Each process that wishes to use a resource performs a wait( ) operation on the
semaphore (thereby decrementing the count).
o When a process releases a resource, it performs a signal( ) operation
(incrementing the count).
o When the count for the semaphore goes to 0, all resources are being used.
o After that, processes that wish to use a resource will block until the count
becomes greater than 0.

➢ Semaphore implementation:
o The definitions of the wait( ) and signal( ) semaphore operations suffers from
busy waiting.
o To overcome the need from busy waiting, we can modify the definition of the
wait( ) and signal( ) operations as given below.
o We define a semaphore as follows:

typedef struct
{
int value;
struct process *list;
} semaphore;

Each semaphore has an integer value and a list of processes list.

o When a process must wait on a semaphore, it is added to the list of processes.
o A signal( ) operation removes one process from the list of waiting processes and
awakens that process.
o Now, the wait() semaphore operation can be defined as,

wait(semaphore *S)
{
S->value--;
if (S->value < 0)
{
add this process to S->list;
block( );
}
}
36
UNIT II NOTES

o The signal() semaphore operation can be defined as,

signal(semaphore *S)
{
S->value++;
if (S->value <= 0)
{
remove a process P from S->list;
wakeup(P);
}
}
o The block( ) operation suspends the process that invokes it.
o The wakeup(P) operation resumes the execution of a blocked process P.
o The list of waiting processes can be easily implemented by a link field in each
process control block (PCB).
o Each semaphore contains an integer value and a pointer to a list of PCBs.
o One way to add and remove processes from the list so as to ensure bounded
waiting is to use a FIFO queue, where the semaphore contains both head and tail
pointers to the queue.

➢ Deadlocks & starvation:

o Deadlocks:
▪ The implementation of a semaphore with a waiting queue may result in a
situation where two or more processes are waiting indefinitely for an event
that can be caused only by one of the waiting processes.
▪ When such a state is reached, these processes are said to be deadlocked.
o Example of deadlock:
▪ consider a system consisting of two processes, P0 and P1, each accessing
two semaphores, S and Q, set to the value 1:
P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
. .
. .
. .
signal(S); signal(Q);
signal(Q); signal(S);
▪ Suppose that P0 executes wait(S) and then P1 executes wait(Q).
▪ When P0 executes wait(Q), it must wait until P1 executes signal(Q).

37
UNIT II NOTES

▪ Similarly, when P1 executes wait(S), it must wait until P0 executes

signal(S). Since these signal( ) operations cannot be executed, P0 and P1
are deadlocked.
▪ We say that a set of processes is in a deadlocked state when every process
in the set is waiting for an event that can be caused only by another
process in the set.
o Starvation:
▪ Another problem related to deadlocks is indefinite blocking or starvation,
a situation in which processes wait indefinitely within the semaphore.
▪ Indefinite blocking may occur if we remove processes from the list
associated with a semaphore in LIFO (last-in, first-out) order.

➢ Priority inversion:
o A scheduling challenge arises when a higher-priority process needs to read or
modify kernel data that are currently being accessed by a lower-priority process—
or a chain of lower-priority processes.
o Example of priority inversion:
▪ Assume we have three processes—L, M, and H—whose priorities follow
the order L < M < H.
▪ Assume that process H requires resource R, which is currently being
accessed by process L.
▪ Ordinarily, process H would wait for L to finish using resource R.
▪ However, now suppose that process M becomes runnable, thereby
preempting process L.
▪ Indirectly, a process with a lower priority—process M—has affected how
long process H must wait for L to relinquish resource R.
▪ This problem is known as priority inversion.
▪ It occurs only in systems with more than two priorities.

38
UNIT II NOTES

Classic problems of synchronization

➢ The Bounded-Buffer Problem
➢ The Readers–Writers Problem
➢ The Dining-Philosophers Problem

The Bounded-Buffer Problem:

✓ Also known as producer-consumer problem.
✓ A producer process produces information that is consumed by a consumer
process.
✓ The producer's job is to generate a piece of data, put it into the buffer and start
again.
✓ At the same time, the consumer is consuming the data (i.e., removing it from the
buffer) one piece at a time.
✓ The problem is to make sure that the producer won't try to add data into the buffer
if it's full and that the consumer won't try to remove data from an empty buffer.
✓ The producer and consumer processes share the following data structures:
int n;
semaphore mutex = 1;
semaphore empty = n;
semaphore full = 0
✓ We assume that the pool consists of n buffers, each capable of holding one item.
✓ The mutex semaphore provides mutual exclusion for accesses to the buffer pool
and is initialized to the value 1.
✓ The empty and full semaphores count the number of empty and full buffers.
✓ The semaphore empty is initialized to the value n; the semaphore full is initialized
to the value 0.

39
UNIT II NOTES

✓ The code for the producer process is shown in Figure 5.9, and the code for the
consumer process is shown in Figure 5.10.

The Readers–Writers Problem:

✓ Suppose that a database is to be shared among several concurrent processes.
✓ Some of these processes may want only to read the database, whereas others may
want to update (that is, to read and write) the database.
✓ We distinguish between these two types of processes by referring to the former as
readers and to the latter as writers.
✓ Obviously, if two readers access the shared data simultaneously, no adverse
effects will result.
✓ However, if a writer and some other process (either a reader or a writer) access
the database simultaneously, chaos may ensue.
✓ To ensure that these difficulties do not arise, we require that the writers have
exclusive access to the shared database while writing to the database. This
synchronization problem is referred to as the readers–writers problem.
✓ The readers–writers problem has several variations, all involving priorities.
✓ The simplest one, referred to as the first readers–writers problem, requires that no
reader be kept waiting unless a writer has already obtained permission to use the
shared object. In other words, no reader should wait for other readers to finish
simply because a writer is waiting.
✓ The second readers–writers problem requires that, once a writer is ready, that
writer perform its write as soon as possible.
✓ In other words, if a writer is waiting to access the object, no new readers may start
reading.

40
UNIT II NOTES

✓ A solution to either problem may result in starvation. In the first case, writers may
starve; in the second case, readers may starve.
✓ In the solution to the first readers–writers problem, the reader processes share the
following data structures:
semaphore rw_mutex = 1;
semaphore mutex = 1;
int read_count = 0;
✓ The semaphores mutex and rw_mutex are initialized to 1; read count is initialized
to 0. The semaphore rw mutex is common to both reader and writer processes.
✓ The mutex semaphore is used to ensure mutual exclusion when the variable read
count is updated.
✓ The read_count variable keeps track of how many processes are currently reading
the object.
✓ The semaphore rw_mutex functions as a mutual exclusion semaphore for the
writers.
✓ It is also used by the first or last reader that enters or exits the critical section. It is
not used by readers who enter or exit while other readers are in their critical
sections.

The Dining-Philosophers Problem:

✓ Consider five philosophers who spend their lives thinking and eating. The
philosophers share a circular table surrounded by five chairs, each belonging to
one philosopher. In the center of the table is a bowl of rice, and the table is laid
with five single chopsticks (Figure 5.13).
✓ When a philosopher thinks, she does not interact with her colleagues. From time
to time, a philosopher gets hungry and tries to pick up the two chopsticks that are
41
UNIT II NOTES

closest to her (the chopsticks that are between her and her left and right
neighbors). A philosopher may pick up only one chopstick at a time. Obviously,
she cannot pick up a chopstick that is already in the hand of a neighbor. When a
hungry philosopher has both her chopsticks at the same time, she eats without
releasing the chopsticks. When she is finished eating, she puts down both
chopsticks and starts thinking again.
✓ The dining-philosophers problem is considered a classic synchronization problem
neither because of its practical importance nor because computer scientists dislike
philosophers but because it is an example of a large class of concurrency-control
problems. It is a simple representation of the need to allocate several resources
among several processes in a deadlock-free and starvation-free manner.
✓ One simple solution is to represent each chopstick with a semaphore. A
philosopher tries to grab a chopstick by executing a wait() operation on that
semaphore. She releases her chopsticks by executing the signal() operation on the
appropriate semaphores. Thus, the shared data are

where all the elements of chopstick are initialized to 1. The structure of

philosopher i is shown in Figure 5.14.
✓ Several possible remedies to the deadlock problem are replaced by:
▪ Allow at most four philosophers to be sitting simultaneously at the table.
▪ Allow a philosopher to pick up her chopsticks only if both chopsticks are
available (to do this, she must pick them up in a critical section).
▪ Use an asymmetric solution—that is, an odd-numbered philosopher picks
up first her left chopstick and then her right chopstick, whereas an even
numbered philosopher picks up her right chopstick and then her left
chopstick.

42
UNIT II NOTES

Monitors

➢ Monitor usage
➢ Dining philosophers solution using monitors
➢ Implementing a monitor using semaphores

o Monitor usage:
✓ A monitor type is an Abstract Data Type that includes a set of programmer
defined operations that are provided with mutual exclusion within the monitor.
✓ The monitor type also declares the variables whose values define the state of an
instance of that type, along with the bodies of functions that operate on those
variables.
✓ The syntax of a monitor type is shown in Figure 5.15.

✓ The schematic view of a monitor type is shown in Figure 5.16.

43
UNIT II NOTES

✓ The definition of condition is given by,

condition x, y;
✓ The only operations that can be invoked on a condition variable are wait( ) and
signal( ).
✓ The operation
x.wait( );
means that the process invoking this operation is suspended until another process
invokes
x.signal( );

✓ Now suppose that, when the x.signal( ) operation is invoked by a process P, there
exists a suspended process associated with condition x.
✓ Clearly, if the suspended process Q is allowed to resume its execution, the
signalling process P must wait.
✓ Otherwise, both P and Q would be active simultaneously within the monitor.
Note, however, that conceptually both processes can continue with their
execution.
44
UNIT II NOTES

✓ Two possibilities exist:

i. Signal and wait. P either waits until Q leaves the monitor or waits
for another condition.
ii. Signal and continue. Q either waits until P leaves the monitor or
waits for another condition.

o Dining philosophers solution using monitors:

✓ Dining philosophers Problem:
▪ Consider five philosophers who spend their lives thinking and eating.
▪ The philosophers share a circular table surrounded by five chairs, each
belonging to one philosopher.
▪ In the center of the table is a bowl of rice, and the table is laid with five
single chopsticks (Figure 5.13).

▪ When a philosopher thinks, she does not interact with her colleagues.
▪ From time to time, a philosopher gets hungry and tries to pick up the two
chopsticks that are closest to her (the chopsticks that are between her and
her left and right neighbors).
▪ A philosopher may pick up only one chopstick at a time.
▪ Obviously, she cannot pick up a chopstick that is already in the hand of a
neighbor.
▪ When a hungry philosopher has both her chopsticks at the same time, she
eats without releasing the chopsticks.
▪ When she is finished eating, she puts down both chopsticks and starts
thinking again.

45
UNIT II NOTES

✓ Dining philosophers Solution:

▪ We illustrate monitor concepts by presenting a deadlock-free solution to
the dining-philosophers problem.

▪ This solution imposes the restriction that a philosopher may pick up her
chopsticks only if both of them are available.

46
UNIT II NOTES

▪ To code this solution, we need to distinguish among three states in which

we may find a philosopher.
▪ For this purpose, we introduce the following data structure:
enum {THINKING, HUNGRY, EATING} state[5];

Philosopher i can set the variable state[i] = EATING,

only if her two neighbors are not eating: (state[(i+4) % 5] != EATING)
and(state[(i+1) % 5] != EATING).
▪ We also need to declare
condition self[5];
▪ This allows philosopher i to delay herself when she is hungry but is unable
to obtain the chopsticks she needs.
▪ We are now in a position to describe our solution to the dining
philosophers problem.
▪ The distribution of the chopsticks is controlled by the monitor Dining
Philosophers, whose definition is shown in Figure 5.18.
▪ Each philosopher, before starting to eat, must invoke the operation pickup(
).
▪ This act may result in the suspension of the philosopher process. After the
successful completion of the operation, the philosopher may eat.
▪ Following this, the philosopher invokes the putdown( ) operation. Thus,
philosopher i must invoke the operations pickup( ) and putdown( ) in the
following sequence:
DiningPhilosophers.pickup(i);
...
eat
...
DiningPhilosophers.putdown(i);

o Implementing a monitor using semaphores:

✓ For each monitor, a semaphore mutex (initialized to 1) is provided.
✓ A process must execute wait(mutex) before entering the monitor and must
execute signal(mutex) after leaving the monitor.
✓ Since a signaling process must wait until the resumed process either leaves or
waits, an additional semaphore, next, is introduced, initialized to 0.
✓ The signaling processes can use next to suspend themselves.
✓ An integer variable next count is also provided to count the number of processes
suspended on next.

47
UNIT II NOTES

✓ Thus, each external function F is replaced by,

✓ The operation x.wait( ) can now be implemented as,

✓ The operation x.signal( ) can be implemented as,

48
UNIT II NOTES

CPU Scheduling
➢ Basic concepts
➢ Scheduling criteria
➢ Scheduling algorithms
o FCFS Scheduling
o SJF Scheduling
o Priority Scheduling
o Round-Robin Scheduling
o Multilevel Queue Scheduling
o Multilevel Feedback Queue Scheduling
➢ Multiprocessor scheduling
➢ Real time scheduling

➢ Basic concepts:
a. CPU–I/O Burst Cycle
b. CPU Scheduler
c. Preemptive Scheduling
d. Dispatcher

a. CPU–I/O Burst Cycle:

49
UNIT II NOTES

- Process execution consists of a cycle of CPU execution and I/O wait.

- Processes alternate between these two states.
- Process execution begins with a CPU burst.
- That is followed by an I/O burst, which is followed by another CPU burst, then
another I/O burst, and so on.
- Eventually, the final CPU burst ends with a system request to terminate execution
(Figure 6.1).

b. CPU Scheduler:
- Whenever the CPU becomes idle, the operating system must select one of the
processes in the ready queue to be executed.
- The selection process is carried out by the short-term scheduler, or CPU scheduler.

c. Preemptive Scheduling:
- CPU-scheduling decisions may take place under the following four circumstances:
1. When a process switches from the running state to the waiting state.
2. When a process switches from the running state to the ready state.
3. When a process switches from the waiting state to the ready state.
4. When a process terminates.
- When scheduling takes place only under circumstances 1 and 4, we say that the
scheduling scheme is nonpreemptive or cooperative. Otherwise, it is preemptive.

d. Dispatcher:
- The dispatcher is the module that gives control of the CPU to the process selected by
the short-term scheduler.
- This function involves the following:
o Switching context
o Switching to user mode
o Jumping to the proper location in the user program to restart that program
- Merit of dispatcher:
o The dispatcher should be as fast as possible, since it is invoked during every
process switch.
- The time it takes for the dispatcher to stop one process and start another running is
known as the dispatch latency.

➢ Scheduling criteria:
o CPU utilization
o Throughput
o Turnaround time

50
UNIT II NOTES

o Waiting time
o Response time

o CPU utilization:
▪ We want to keep the CPU as busy as possible.
▪ Conceptually, CPU utilization can range from 0 to 100 percent.
▪ In a real system, it should range from 40 percent to 90 percent.

o Throughput:
▪ The number of processes that are completed per time unit, called
throughput.

o Turnaround time:
▪ The interval from the time of submission of a process to the time of
completion is the turnaround time.

o Waiting time:
▪ Waiting time is the sum of the periods spent waiting in the ready queue.

o Response time:
▪ The time from the submission of a request until the first response is
produced is called the response time.

➢ Scheduling algorithms:
o FCFS Scheduling:
▪ By far the simplest CPU-scheduling algorithm is the first-come, first-
served (FCFS) scheduling algorithm.
▪ With this scheme, the process that requests the CPU first is allocated the
CPU first.
▪ The implementation of the FCFS policy is easily managed with a FIFO
queue.
▪ Merit:
• Simple
• The code for FCFS scheduling is simple to write and understand.
▪ Demerit:
• The average waiting time under the FCFS policy is often quite
long.

51
UNIT II NOTES

o SJF Scheduling:
▪ This algorithm associates with each process the length of the process’s
next CPU burst.
▪ When the CPU is available, it is assigned to the process that has the
smallest next CPU burst.
▪ If the next CPU bursts of two processes are the same, FCFS scheduling is
used to break the tie.
▪ Merit:
▪ It gives the minimum average waiting time for a given set of
processes.
▪ Demerit:
▪ Knowing the length of the next CPU request is difficult.
▪ Used frequently in long-term scheduling.

o Priority Scheduling:
▪ A priority is associated with each process, and the CPU is allocated to the
process with the highest priority.
▪ Equal-priority processes are scheduled in FCFS order.
▪ Priority scheduling can be either preemptive or nonpreemptive.
▪ When a process arrives at the ready queue, its priority is compared with
the priority of the currently running process.
▪ A preemptive priority scheduling algorithm will preempt the CPU if the
priority of the newly arrived process is higher than the priority of the
currently running process.
▪ A nonpreemptive priority scheduling algorithm will simply put the new
process at the head of the ready queue.
▪ Demerit:
▪ A major problem is indefinite blocking, or starvation.

o Round-Robin Scheduling:
▪ The round-robin (RR) scheduling algorithm is designed especially for
timesharing systems.
▪ It is similar to FCFS scheduling, but preemption is added to enable the
system to switch between processes.
▪ A small unit of time, called a time quantum or time slice, is defined.
▪ A time quantum is generally from 10 to 100 milliseconds in length.
▪ The ready queue is treated as a circular queue.
▪ The CPU scheduler goes around the ready queue, allocating the CPU to
each process for a time interval of up to 1 time quantum.
52
UNIT II NOTES

▪To implement RR scheduling, we again treat the ready queue as a FIFO

queue of processes.
▪ Demerit:
▪ The average waiting time under the RR policy is often long.
o Multilevel Queue Scheduling:
▪ A multilevel queue scheduling algorithm partitions the ready queue into
several separate queues (Figure 6.6).
▪ The processes are permanently assigned to one queue, generally based on
some property of the process, such as memory size, process priority, or
process type.
▪ Each queue has its own scheduling algorithm.
▪ For example, separate queues might be used for foreground and
background processes.
▪ The foreground queue might be scheduled by an RRalgorithm, while the
background queue is scheduled by an FCFS algorithm.

▪ An example of a multilevel queue scheduling algorithm with five queues,

listed below in order of priority:
1. System processes
2. Interactive processes
3. Interactive editing processes
4. Batch processes
53
UNIT II NOTES

5. Student processes
▪ Each queue has absolute priority over lower-priority queues. Another
possibility is to time-slice among the queues.

o Multilevel Feedback Queue Scheduling:

▪ The multilevel feedback queue scheduling algorithm, in contrast, allows a
process to move between queues.
▪ The idea is to separate processes according to the characteristics of their
CPU bursts.
▪ If a process uses too much CPU time, it will be moved to a lower-priority
queue.
▪ This scheme leaves I/O-bound and interactive processes in the higher-
priority queues.
▪ In addition, a process that waits too long in a lower-priority queue may be
moved to a higher-priority queue. This form of aging prevents starvation.

▪ In general, a multilevel feedback queue scheduler is defined by the

following parameters:
▪ The number of queues.
▪ The scheduling algorithm for each queue.
▪ The method used to determine when to upgrade a process to a
higher priority queue.
▪ The method used to determine when to demote a process to a lower
priority queue.
▪ The method used to determine which queue a process will enter
when that process needs service.
54
UNIT II NOTES

Deadlocks
➢ Definition of Deadlocks
➢ Deadlock Characterization
➢ Methods for Handling Deadlocks
➢ Deadlock Prevention
➢ Deadlock Avoidance
➢ Deadlock Detection
➢ Recovery from Deadlock

➢ Definition of Deadlocks:
o A process requests resources; if the resources are not available at that time, the
process enters a waiting state. Sometimes, a waiting process is never again able to
change state, because the resources it has requested are held by other waiting
processes. This situation is called a deadlock.

➢ Deadlock Characterization:
o Necessary Conditions
o Resource-Allocation Graph

o Necessary Conditions:
▪ A deadlock situation can arise if the following four conditions hold
simultaneously in a system:
1. Mutual exclusion
2. Hold and wait.
3. No pre-emption
4. Circular wait

Mutual exclusion:
▪ At least one resource must be held in a non-sharable mode; that is,
only one process at a time can use the resource.

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 pre-emption:

55
UNIT II NOTES

▪ 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, ..., Pn} of waiting processes must exist such that,
• P0 is waiting for a resource held by P1,
• P1 is waiting for a resource held by P2, ...,
• Pn−1 is waiting for a resource held by Pn, and
• Pn is waiting for a resource held by P0.

o Resource-Allocation Graph:
▪ Deadlocks can be described more precisely in terms of a directed graph
called a system resource-allocation graph.
▪ This graph consists of a set of vertices V and a set of edges E.
▪ The set of vertices V is partitioned into two different types of nodes: P =
{P1, P2, ..., Pn}, the set consisting of all the active processes in the system,
and R = {R1, R2, ..., Rm}, the set consisting of all resource types in the
system.
▪ 2 types of edges,
• Request edge
• Assignment edge

Request edge Assignment edge

A directed edge from process Pi to A directed edge from resource type Rj to

resource type Rj is denoted by Pi → Rj ; it process Pi is denoted by Rj → Pi ; it
signifies that process Pi has requested an signifies that an instance of resource type
instance of resource type Rj and is Rj has been allocated to process Pi .
currently waiting for that resource.

A directed edge Pi → Rj is called a A directed edge Rj → Pi is called an

request edge. assignment edge.

56
UNIT II NOTES

▪ The resource-allocation graph shown in Figure 7.1 depicts the following

situation.
▪ The sets P, R, and E:
◦ P = {P1, P2, P3}
◦ R = {R1, R2, R3, R4}
◦ E = {P1 → R1, P2 → R3, R1 → P2, R2 → P2, R2 → P1, R3 → P3}
▪ Resource instances:
◦ One instance of resource type R1
◦ Two instances of resource type R2
◦ One instance of resource type R3
◦ Three instances of resource type R4
▪ Process states:
◦ Process P1 is holding an instance of resource type R2 and is waiting for
an instance of resource type R1.
◦ Process P2 is holding an instance of R1 and an instance of R2 and is
waiting for an instance of R3.
◦ Process P3 is holding an instance of R3.
▪ Given the definition of a resource-allocation graph, it can be shown that, if
the graph contains no cycles, then no process in the system is deadlocked.
If the graph does contain a cycle, then a deadlock may exist.

57
UNIT II NOTES

58
UNIT II NOTES

➢ Methods for Handling Deadlocks:

o Deadlock prevention
o Deadlock avoidance
o Deadlock detection
o Deadlock recovery

➢ Deadlock Prevention:
o Mutual exclusion
o Hold and wait
o No pre-emption
o Circular wait

o Mutual exclusion:
▪ The mutual exclusion condition must hold. That is, at least one resource
must be nonsharable.
▪ Sharable resources, in contrast, do not require mutually exclusive access
and thus cannot be involved in a deadlock.
▪ Read-only files are a good example of a sharable resource.
▪ A process never needs to wait for a sharable resource.
▪ In general, however, we cannot prevent deadlocks by denying the mutual-
exclusion condition.

o Hold and wait:

▪ To ensure that the hold-and-wait condition never occurs in the system, we
must guarantee that, whenever a process requests a resource, it does not
hold any other resources.
▪ One protocol that we can use requires each process to request and be
allocated all its resources before it begins execution.
▪ An alternative protocol allows a process to request resources only when it
has none.
▪ Disadvantages of these protocols:
• Resource utilization may be low, since resources may be allocated
but unused for a long period.
• Second, starvation is possible.

o No pre-emption:
▪ The third necessary condition for deadlocks is that there be no pre-
emption of resources that have already been allocated.

59
UNIT II NOTES

▪ To ensure that this condition does not hold, we can use the following
protocol.
▪ If a process is holding some resources and requests another resource that
cannot be immediately allocated to it (that is, the process must wait), then
all resources the process is currently holding are preempted.

o Circular wait:
▪ The fourth and final condition for deadlocks is the circular-wait condition.
▪ One way to ensure that this condition never holds is to impose a total
ordering of all resource types and to require that each process requests
resources in an increasing order of enumeration.
▪ To illustrate, we let R = {R1, R2, ..., Rm} be the set of resource types. We
assign to each resource type a unique integer number, which allows us to
compare two resources and to determine whether one precedes another in
our ordering.
▪ Formally, we define a one-to-one function F: R→N, where N is the set of
natural numbers.
▪ For example, if the set of resource types R includes tape drives, disk
drives, and printers, then the function F might be defined as follows:
F(tape drive) = 1
F(disk drive) = 5
F(printer) = 12

60
UNIT II NOTES

➢ Deadlock Avoidance:
o A deadlock-avoidance algorithm dynamically examines the resource-allocation
state to ensure that a circular-wait condition can never exist.
o The resource allocation state is defined by the number of available and allocated
resources and the maximum demands of the processes.
▪ Safe state
▪ Resource-Allocation Graph algorithm
▪ Banker’s algorithm

✓ Safe state:
o A state is safe if the system can allocate resources to each process (up to its
maximum) in some order and still avoid a deadlock.
o More formally, a system is in a safe state only if there exists a safe sequence.
o A sequence of processes <P1, P2, ..., Pn> is a safe sequence for the current
allocation state if, for each Pi , the resource requests that Pi can still make can be
satisfied by the currently available resources plus the resources held by all Pj,
with j < i.
o If no such sequence exists, then the system state is said to be unsafe.
o A safe state is not a deadlocked state.
o Conversely, a deadlocked state is an unsafe state.
o Not all unsafe states are deadlocks, however (Figure 7.6).
o An unsafe state may lead to a deadlock.

61
UNIT II NOTES

✓ Resource-Allocation Graph algorithm:

o In addition to the request and assignment edges already described, we introduce a
new type of edge, called a claim edge.
o A claim edge Pi → Rj indicates that process Pi may request resource Rj at some
time in the future.
o This edge resembles a request edge in direction but is represented in the graph by
a dashed line.

o When process Pi requests resource Rj , the claim edge Pi → Rj is converted to a

request edge.
o Similarly, when a resource Rj is released by Pi , the assignment edge Rj → Pi is
reconverted to a claim edge Pi → Rj .
o If no cycle exists, then the allocation of the resource will leave the system in a
safe state.
o If a cycle is found, then the allocation will put the system in an unsafe state.
o To illustrate this algorithm, we consider the resource-allocation graph of Figure
7.7.

62
UNIT II NOTES

o Suppose that P2 requests R2. Although R2 is currently free, we cannot allocate it to

P2, since this action will create a cycle in the graph (Figure 7.8).
o A cycle, as mentioned, indicates that the system is in an unsafe state. If P1
requests R2, and P2 requests R1, then a deadlock will occur.

✓ Banker’s algorithm:
o The deadlock avoidance algorithm is applicable to such a system but is less
efficient than the resource-allocation graph scheme. This algorithm is commonly
known as the banker’s algorithm.
o The name was chosen because the algorithm could be used in a banking system to
ensure that the bank never allocated its available cash in such a way that it could
no longer satisfy the needs of all its customers.
o the following data structures, where n is the number of processes in the system
and m is the number of resource types:
▪ Available:
• A vector of length m indicates the number of available resources of
each type.
• If Available[j] equals k, then k instances of resource type Rj are
available.

▪ Max:
• An n × m matrix defines the maximum demand of each process.
• If Max[i][j] equals k, then process Pi may request at most k
instances of resource type Rj .
▪ Allocation:
• An n × m matrix defines the number of resources of each type
currently allocated to each process.
• If Allocation[i][j] equals k, then process Pi is currently allocated k
instances of resource type Rj .

▪ Need:
• An n × m matrix indicates the remaining resource need of each
process.
• If Need[i][j] equals k, then process Pi may need k more instances
of resource type Rj to complete its task.
• Note that Need[i][j] equals Max[i][j]− Allocation[i][j].

63
UNIT II NOTES

1. Safety Algorithm
2. Resource-Request Algorithm

Safety Algorithm:
o We can now present the algorithm for finding out whether or not a system
is in a safe state.
o This algorithm can be described as follows:
Step 1:
Let Work and Finish be vectors of length m and n, respectively.
Initialize Work = Available and Finish[i] = false for i = 0, 1, ..., n − 1.

Step 2:
Find an index i such that both
a. Finish[i] == false
b. Needi ≤Work
If no such i exists, go to step 4.

Step 3:
Work =Work + Allocationi
Finish[i] = true
Go to step 2.

Step 4:
If Finish[i] == true for all i, then the system is in a safe state.

Resource-Request Algorithm:
o Next, we describe the algorithm for determining whether requests can be
safely granted.
Let Requesti be the request vector for process Pi . If Requesti [ j] == k, then
process Pi wants k instances of resource type Rj .
When a request for resources is made by process Pi , the following actions are
taken:
Step 1:
If Requesti ≤Needi , go to step 2. Otherwise, raise an error condition, since the
process has exceeded its maximum claim.

Step 2:
64
UNIT II NOTES

If Requesti ≤ Available, go to step 3. Otherwise, Pi must wait, since the resources

are not available.

Step 3:
Have the system pretend to have allocated the requested resources to process Pi
by modifying the state as follows:
Available = Available–Requesti ;
Allocationi = Allocationi + Requesti ;
Needi = Needi –Requesti ;

If the resulting resource-allocation state is safe, the transaction is completed, and

process Pi is allocated its resources. However, if the new state is unsafe, then Pi must
wait for Requesti , and the old resource-allocation state is restored.

65
UNIT II NOTES

➢ Deadlock Detection:
o If a system does not employ either a deadlock-prevention or a deadlock avoidance
algorithm, then a deadlock situation may occur.
o In this environment, the system may provide:
▪ An algorithm that examines the state of the system to determine whether a
deadlock has occurred.
▪ An algorithm to recover from the deadlock

- Single Instance of Each Resource Type

- Instances of a Resource Type
- Detection-Algorithm Usage

✓ Single Instance of Each Resource Type:

❖ If all resources have only a single instance, then we can define a deadlock
detection algorithm that uses a variant of the resource-allocation graph, called
a wait-for graph.
❖ We obtain this graph from the resource-allocation graph by removing the
resource nodes and collapsing the appropriate edges.
❖ In Figure 7.9, we present a resource-allocation graph and the corresponding
wait-for graph.

66
UNIT II NOTES

✓ Several Instances of a Resource Type:

❖ The wait-for graph scheme is not applicable to a resource-allocation system
with multiple instances of each resource type.
❖ We turn now to a deadlock detection algorithm that is applicable to such a
system.
❖ The algorithm employs several time-varying data structures that are similar to
those used in the banker’s algorithm:
▪ Available:
• A vector of length m indicates the number of available
resources of each type.

▪ Allocation:
• An n × m matrix defines the number of resources of each type
currently allocated to each process.

▪ Request:
• An n × m matrix indicates the current request of each process.
• If Request[i][j] equals k, then process Pi is requesting k more
instances of resource type Rj .
Step 1:
Let Work and Finish be vectors of length m and n, respectively.
Initialize Work = Available. For i = 0, 1, ..., n–1, if Allocationi!= 0, then
Finish[i] = false. Otherwise, Finish[i] = true.

Step 2:
Find an index i such that both
a. Finish[i] == false
b. Requesti ≤Work
If no such i exists, go to step 4.

Step 3:
Work =Work + Allocationi
Finish[i] = true
Go to step 2.

Step 4:
If Finish[i] ==false for some i, 0≤i<n, then the system is in a deadlocked state.
Moreover, if Finish[i] == false, then process Pi is deadlocked.

67
UNIT II NOTES

✓ Detection-Algorithm Usage:
❖ When should we invoke the detection algorithm? The answer depends on two
factors:
1. How often is a deadlock likely to occur?
2. How many processes will be affected by deadlock when it happens?

68
UNIT II NOTES

➢ Recovery from Deadlock:

o There are two options for breaking a deadlock.
▪ One is simply to abort one or more processes to break the circular wait.
▪ The other is to preempt some resources from one or more of the
deadlocked processes.

✓ Process Termination
✓ Resource Preemption

✓ Process Termination:
❖ Abort all deadlocked processes:
▪ This method clearly will break the deadlock cycle, but at great
expense.
▪ The deadlocked processes may have computed for a long time, and the
results of these partial computations must be discarded and probably
will have to be recomputed later.
❖ Abort one process at a time until the deadlock cycle is eliminated:
▪ This method incurs considerable overhead, since after each process is
aborted, a deadlock-detection algorithm must be invoked to determine
whether any processes are still deadlocked.

✓ Resource Preemption:
❖ To eliminate deadlocks using resource preemption, we successively pre-empt
some resources from processes and give these resources to other processes
until the deadlock cycle is broken.
❖ If preemption is required to deal with deadlocks, then three issues need to be
addressed:
▪ Selecting a victim:
• Which resources and which processes are to be preempted?

▪ Rollback:
• If we preempt a resource from a process, what should be done
with that process?

▪ Starvation:
• How do we ensure that starvation will not occur? That is, how
can we guarantee that resources will not always be preempted
from the same process?

69