Operating System

Unit II Srinivas Koppu

Associate Professor
SITE

02/08/2022
 Roadmap ( PROCESS MANAGEMENT )

• Scheduling:
 Preemptive and non-preemptive scheduling; scheduling policies
• Concurrency:
• Mutual exclusion
• deadlock detection and prevention; solution strategies;
models and mechanisms
• (semaphores, monitors, condition variables, rendezvous);
producer-consumer problems; synchronization;
multiprocessor issues
Process Concept
• An operating system executes a variety of
programs:
— Batch system – jobs
— Time-shared systems – user programs or tasks
• uses the terms job and process almost
interchangeably.
• Process – a program in execution; process
execution must progress in sequential fashion.
• A process includes:
— program counter
— stack
— data section
What is a “process” ?
• A program in execution
• An instance of a program running on a
computer
• The entity that can be assigned to and
executed on a processor
• A unit of activity characterized by the
execution of a sequence of instructions, a
current state, and an associated set of
system instructions.
Process State
• As a process executes, it changes state
—new: The process is being created.
—running: Instructions are being executed.
—waiting: The process is waiting for some
event to occur.
—ready: The process is waiting to be assigned
to a process.
—terminated: The process has finished
execution.
Diagram of Process State
•
Two-State Process Model
• Process may be in one of two states
— Running
— Not-running
Queuing Diagram
•

Etc … processes moved by the dispatcher of the OS to the CPU

then back to the queue until the task is competed
Process Birth and Death
• Creation Termination
New batch job Normal Completion
Interactive Login Memory unavailable
Created by OS to
provide a service Protection error
Spawned by
existing process Operator or OS
Intervention
Process Creation
• The OS builds a data structure to manage
the process
• Traditionally, the OS created all processes
—But it can be useful to let a running process
create another
• This action is called process spawning
—Parent Process is the original, creating,
process
—Child Process is the new process
Process Termination
• There must be some way that a process
can indicate completion.
• This indication may be:
—A HALT instruction generating an interrupt
alert to the OS.
—A user action (e.g. log off, quitting an
application)
—A fault or error
—Parent process terminating
Process Control Block (PCB)
•
Information associated with each process.
Process state
Program counter
CPU registers
CPU scheduling information
Memory-management information
Accounting information
I/O status information
Process Control Block (PCB)
•
CPU Switch From Process to Process
•
Process Scheduling Queues
• Job queue – set of all processes in the system.
Ready queue – set of all processes residing in main
memory, ready and waiting to execute.
Device queues – set of processes waiting for an I/O
device.
Process migration between the various queues.
Ready Queue And Various I/O Device Queues
•
Representation of Process Scheduling
•
Five-State Process Model
Using Two Queues
Multiple Blocked Queues
Suspended Processes

• Processor is faster than I/O so all

processes could be waiting for I/O
—Swap these processes to disk to free up more
memory and use processor on more processes
• Blocked state becomes suspend state
when swapped to disk
• Two new states
—Blocked/Suspend
—Ready/Suspend
Schedulers
•
Long-term scheduler (or job scheduler) – selects which
processes should be brought into the ready queue.

Short-term scheduler (or CPU scheduler) – selects which

process should be executed next and allocates CPU.
Addition of Medium Term Scheduling
•
Schedulers (Cont.)
• Short-term scheduler is invoked very frequently
(milliseconds)  (must be fast).
• Long-term scheduler is invoked very infrequently (seconds,
minutes)  (may be slow).
• The long-term scheduler controls the degree of
multiprogramming.
• Processes can be described as either:
—I/O-bound process – spends more time doing I/O than
computations, many short CPU bursts.
—CPU-bound process – spends more time doing
computations; few very long CPU bursts.
Context Switch
• When CPU switches to another process, the system must
save the state of the old process and load the saved state for
the new process.
• Context-switch time is overhead; the system does no useful
work while switching.
• Time dependent on hardware support.
Process Creation
• Parent process create children processes,
which, in turn create other processes,
forming a tree of processes.
• Resource sharing
—Parent and children share all resources.
—Children share subset of parent’s resources.
—Parent and child share no resources.
• Execution
—Parent and children execute concurrently.
—Parent waits until children terminate.
Process Creation (Cont.)
• Address space
—Child duplicate of parent.
—Child has a program loaded into it.
• UNIX examples
—fork system call creates new process
—exec system call used after a fork to replace
the process’ memory space with a new
program.
Processes Tree on a UNIX System
Process Termination
• Process executes last statement and asks
the operating system to decide it (exit).
—Output data from child to parent (via wait).
—Process’ resources are deallocated by
operating system ( I/O files , Buffers,virtual
Meory )
• Parent may terminate execution of
children processes (abort).
—Child has exceeded allocated resources.
—Task assigned to child is no longer required.
—Parent is exiting.
– Operating system does not allow child to continue if
its parent terminates.
– Cascading termination.
Cooperating Processes ( Concurrent )
• Independent process cannot affect or be
affected by the execution of another
process ( Does not share any data (Temp
or Persistent ))
• Cooperating process can affect or be
affected by the execution of another
process
• Advantages of process cooperation
—Information sharing ( Shared files )
—Computation speed-up ( CPU or I/O Channels)
—Modularity
—Convenience
Producer-Consumer Problem
• Paradigm for cooperating processes,
producer process produces information
that is consumed by a consumer process.
—unbounded-buffer places no practical limit on
the size of the buffer.
—bounded-buffer assumes that there is a fixed
buffer size. ( Consumer must wait if the Buffer
is empty and producer must wait if the buffer
is full )
 Bounded-Buffer – Shared-Memory Solution

• Shared data
#define BUFFER_SIZE 10
Typedef struct {
...
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
• Solution is correct, but can only use
BUFFER_SIZE-1 elements
Bounded-Buffer – Producer Process

item nextProduced;

while (1) {
while (((in + 1) % BUFFER_SIZE) ==
out) //Buffer full
; /* do nothing */
buffer[in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
}
Bounded-Buffer – Consumer Process

item nextConsumed;

while (1) {
while (in == out) // Empty
; /* do nothing */
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
}
Interprocess Communication (IPC)
• Mechanism for processes to communicate and to synchronize
their actions.
• Message system – processes communicate with each other
without resorting to shared variables.
• IPC facility provides two operations:
—send(message) – message size fixed or variable
—receive(message)
• If P and Q wish to communicate, they need to:
—establish a communication link between them
—exchange messages via send/receive
• Implementation of communication link
—physical (e.g., shared memory, hardware bus)
—logical (e.g., logical properties)
Implementation Questions
• How are links established?
• Can a link be associated with more than
two processes?
• How many links can there be between
every pair of communicating processes?
• What is the capacity of a link?
• Is the size of a message that the link can
accommodate fixed or variable?
• Is a link unidirectional or bi-directional?
Addressing

• Sending process need to be able to specify

which process should receive the message
—Direct addressing
—Indirect Addressing
Direct Communication

• Send primitive includes a specific identifier

of the destination process
• Receive primitive could know ahead of
time which process a message is expected
• Receive primitive could use source
parameter to return a value when the
receive operation has been performed
Direct Communication…
• Processes must name each other explicitly:
—send (P, message) – send a message to process P
—receive(Q, message) – receive a message from process Q
• Properties of communication link
—Links are established automatically.
—A link is associated with exactly one pair of
communicating processes.
—Between each pair there exists exactly one link.
—The link may be unidirectional, but is usually bi-
directional.
Indirect Communication
• Messages are directed and received from mailboxes
(also referred to as ports).
—Each mailbox has a unique id.
—Processes can communicate only if they share a
mailbox.
• Properties of communication link
—Link established only if processes share a common
mailbox
—A link may be associated with many processes.
—Each pair of processes may share several
communication links.
—Link may be unidirectional or bi-directional.
Indirect Communication

• Operations
—create a new mailbox
—send and receive messages through
mailbox
—destroy a mailbox
• Primitives are defined as:
send(A, message) – send a message
to mailbox A
receive(A, message) – receive a
message from mailbox A
Indirect Communication
• Mailbox sharing
—P1, P2, and P3 share mailbox A.
—P1, sends; P2 and P3 receive.
—Who gets the message?
• Solutions
—Allow a link to be associated with at most two
processes.
—Allow only one process at a time to execute a
receive operation.
—Allow the system to select arbitrarily the
receiver ( either p2 or p3 ). Sender is notified
who the receiver was.
Indirect Process Communication
General Message Format
Synchronization
• Message passing may be either blocking
or non-blocking.
• Blocking is considered synchronous
• Non-blocking is considered
asynchronous
• send and receive primitives may be
either blocking or non-blocking.
Synchronization conti…
• Blocking Send: the sending process is
blocked until the message is received by
the receiving process or by mailbox.
• Non blocking Send: the sending process
sends the message and resumes the
operation.
• Blocking receive: the receiver blocks until
a message is available.
• Non blocking receive: the receiver
retrieves either a valid message or Null.
Buffering
• Queue of messages attached to the link;
implemented in one of three ways.
1. Zero capacity – 0 messages
Sender must wait for receiver (rendezvous).
2. Bounded capacity – finite length of n
messages
Sender must wait if link full.
3. Unbounded capacity – infinite length
Sender never waits.
Client-Server Communication
• Sockets
• Remote Procedure Calls
• Remote Method Invocation (Java)
Sockets
• A socket is defined as an endpoint for
communication.
• Concatenation of IP address and port
• The socket 161.25.19.8:1625 refers to
port 1625 on host 161.25.19.8
• Communication consists between a pair of
sockets.
Socket Communication
Processes and Threads
• The unit of dispatching is referred to as a
thread or lightweight process
• The unit of resource ownership is referred
to as a process or task
•
Multithreading

• The ability of an
OS to support
multiple,
concurrent paths
of execution within
a single process.
Single Thread
Approaches

• MS-DOS supports a
single user process
and a single thread.
• Some UNIX, support
multiple user
processes but only
support one thread
per process
Multithreading

• Java run-time
environment is a
single process with
multiple threads
• Multiple processes
and threads are found
in Windows, Solaris,
and many modern
versions of UNIX
One or More Threads in Process

• Each thread has

—An execution state (running, ready, etc.)
—Saved thread context when not running
—An execution stack
—Some per-thread static storage for local
variables
—Access to the memory and resources of its
process (all threads of a process share this)
Threads and processes

• Takes less time to create a new thread

than a process
• Less time to terminate a thread than a
process
• Switching between two threads takes less
time that switching processes
• Threads can communicate with each other
—without invoking the kernel
Threads

• Several actions that affect all of the

threads in a process
—The OS must manage these at the process
level.
• Examples:
—Suspending a process involves suspending all
threads of the process
—Termination of a process, terminates all
threads within the process
Activities similar
to Processes

• Threads have execution states and may

synchronize with one another.
—Similar to processes
• We look at these two aspects of thread
functionality in turn.
—States
—Synchronisation
Thread Execution States

• States associated with a change in thread

state
—Spawn (another thread)
—Block
– Issue: will blocking a thread block other, or all,
threads
—Unblock
—Finish (thread)
– Deallocate register context and stacks
One view…

• One way to view a thread is as an

independent program counter operating
within a process.
Single and Multithreaded Processes
Benefits
• Responsiveness
• Foreground and background work

• Resource Sharing

• Economy

• Utilization of MP Architectures
User levelThreads
• Thread management done by user-level
threads library.
• Library supports thread creation and
destroying ,scheduling and Management
with no support from kernel.
• User level thread are fast to create and
manage .

• Examples
- POSIX Pthreads
- Mach C-threads
- Solaris threads
User-Level Threads

• All thread
management is done
by the application
• The kernel is not
aware of the
existence of threads
Kernel Level Threads ( OS )
• Supported by the Kernel.
• slower to create and manage.
• Examples
- Windows 95/98/NT/2000
- Solaris
- Tru64 UNIX
- BeOS
- Linux
Kernel-Level Threads

• Kernel maintains context

information for the
process and the threads
—No thread management
done by application
• Scheduling is done on a
thread basis
Advantages of KLT

• The kernel can simultaneously schedule

multiple threads from the same process on
multiple processors.
• If one thread in a process is blocked, the
kernel can schedule another thread of the
same process.
• Kernel routines themselves can be
multithreaded.
Disadvantage of KLT

• The transfer of control from one thread to

another within the same process requires
a mode switch to the kernel
Combined Approaches

• Thread creation done in

the user space
• Bulk of scheduling and
synchronization of
threads by the
application

• Example is Solaris
Multithreading Models
• Many-to-One

• One-to-One

• Many-to-Many
Many-to-One
• Many user-level threads mapped to single
kernel thread.

• Used on systems that do not support

kernel threads.
• Efficient but the entire process will block
if a thread makes a blocking system call .
Many-to-One Model
One-to-One
• Each user-level thread maps to kernel
thread.

• provides more concurrent than previous

case.
• Drawback:
creating a user thread requires creating
the corresponding kernel thread
( Overhead )
• Examples
- Windows 95/98/NT/2000
- OS/2
One-to-one Model
Many-to-Many Model
• Allows many user level threads to be
mapped to many kernel threads.
• Allows the operating system to create a
sufficient number of kernel threads.
• Solaris 2,IRIX,HP-UX and Tru64 Unix
• Windows NT/2000 with the ThreadFiber
package
Many-to-Many Model
 Client and server with threads

Thread 2 makes
requests to server
Receipt & Input-output
queuing
Thread 1
generates
results
T1
Requests
N threads
Client
Server
Threading Issues
• Semantics of fork() and exec() system
calls.
• Thread cancellation.
• Signal handling
• Thread pools
• Thread specific data
Pthreads
• a POSIX standard (IEEE 1003.1c) API for
thread creation and synchronization.
• API specifies behavior of the thread
library, implementation is up to
development of the library.
• Common in UNIX operating systems.
Solaris 2 Threads
Solaris Process
Windows 2000 Threads
• Implements the one-to-one mapping.
• Each thread contains
- a thread id
- register set
- separate user and kernel stacks
- private data storage area
Linux Threads
• Linux refers to them as tasks rather than
threads.
• Thread creation is done through clone()
system call.
• Clone() allows a child task to share the
address space of the parent task (process)
Java Threads
• Java threads may be created by:

—Extending Thread class

—Implementing the Runnable interface

• Java threads are managed by the JVM.

Java Thread States
Basic Concepts
• Maximum CPU utilization obtained with
multiprogramming
• CPU–I/O Burst Cycle – Process execution
consists of a cycle of CPU execution and
I/O wait.
• CPU burst distribution
Alternating Sequence of CPU And I/O Bursts
Histogram of CPU-burst Times
CPU Scheduler
• Selects from among the processes in
memory that are ready to execute, and
allocates the CPU to one of them.
• CPU scheduling decisions may take place
when a process:
1. Switches from running to waiting state.
2. Switches from running to ready state.
3. Switches from waiting to ready.
4. Terminates.
• Scheduling under 1 and 4 is
nonpreemptive.
• All other scheduling is preemptive.
Dispatcher
• Dispatcher module gives control of the
CPU to the process selected by the short-
term scheduler; this involves:
—switching context
—switching to user mode
—jumping to the proper location in the user
program to restart that program
• Dispatch latency – time it takes for the
dispatcher to stop one process and start
another running.
Scheduling Criteria

• CPU utilization – keep the CPU as busy as possible

• Throughput – # of processes that complete their
execution per time unit.
=> Depends on the length of process
• Turnaround time – amount of time to execute a
particular process
•
Turn around Time =Time to get into Memory
+ Waiting time in ready queue
+
Executing time in CPU
+

Wait time in waiting queue for I/O

• Waiting time – amount of time a process has been
waiting in the ready queue
• Response time – amount of time it takes from when
a request was submitted until the first response is
produced, not output (for time-sharing environment)
Optimization Criteria
• Max CPU utilization
• Max throughput
• Min turnaround time
• Min waiting time
• Min response time
First-Come, First-Served (FCFS) Scheduling

ProcessBurst Time
P1 24
P2 3
P3 3
• Suppose that the processes arrive in
the order: P1 , P2 , P3
The Gantt Chart for the schedule is:
P1 P2 P3

0 24 27 30
FCFS Scheduling (Cont.)
Suppose that the processes arrive in the
order
P2 , P3 , P 1 .
• The Gantt chart for the schedule is:
P2 P3 P1

0 3 6 30
• Waiting time for P1 = 6; P2 = 0; P3 = 3
• Average waiting time: (6 + 0 + 3)/3 = 3
• Much better than previous case.
• Convoy effect short process behind long
process
 EXAMPLE - 1

Arrival Time Process CPU Time (or) Burst Time

0 P1 5 Time required by CPU

0 P2 10 to execute job

0 P3 8
0 P4 3

P1 P2 P3 P4
0 5 15 23 26

Gantt Chart
Average Waiting Time:

Waiting Time = Starting Time – Arrival Time

P1 => 0 – 0 = 0
P2 => 5 – 0 = 5
P3 => 15 – 0 = 15
P4 => 23 – 0 = 23

Average waiting Time = 0 + 5 + 15 + 23 / 4

= 43 / 4
=> 10.75ms
Average Turn Around Time:

Turn around time = Finished Time – Arrival Time

P1 = 5 – 0 = 5
P2 = 15 – 0 = 15
P3 = 23 – 0 = 23
P4 = 26 – 0 = 26

Average Turn around Time = 5 + 15 + 23 + 26 / 4

= 69 / 4
=> 17.25ms
Average Response Time:

Response Time = First response – arrival Time

P1 => 0 – 0 = 0
P2 => 5 – 0 = 5
P3 => 15 – 0 = 15
P4 => 23 – 0 = 23

Average Response Time = 0 + 5 + 15 + 23 / 4

= 43 / 4
=> 10.75ms
 Average Waiting Time = 10.75
Average Turn around Time = 17.25
Average Response Time = 10.75
Cons:

 High Turn around & Waiting time

 Low rate of CPU utilization { Bcs of non-preemption}

 Short job have to wait for long time, when the CPU is allocate to long
jobs
 EXAMPLE - 2

Arrival Time Process CPU Time (or) Burst Time

0 P1 3
2 P2 6
4 P3 4
6 P4 5
8 P5 2

P1 P2 P3 P4 P5
0 3 9 13 18 20

Gantt Chart
Shortest-Job-First (SJR) Scheduling
• Associate with each process the length of its next
CPU burst. Use these lengths to schedule the process
with the shortest time.
• Two schemes:
—nonpreemptive – once CPU given to the process it cannot
be preempted until completes its CPU burst.
—preemptive – if a new process arrives with CPU burst
length less than remaining time of current executing
process, preempt. This scheme is know as the
Shortest-Remaining-Time-First (SRTF).
• SJF is optimal – gives minimum average waiting
time for a given set of processes.
 EXAMPLE - 1

Arrival Time Process CPU Time (or) Burst Time

0 P1 5
0 P2 10
0 P3 8
0 P4 3 Shortest CPU time

P4 P1 P3 P2
0 3 8 16 26
Gantt Chart
Average Waiting Time:

Waiting Time = Starting Time – Arrival Time

P1 => 0 – 0 = 0
P2 => 3 – 0 = 3
P3 => 8 – 0 = 8
P4 => 16 – 0 = 16

Average waiting Time = 0 + 3 + 8 + 16 / 4

= 27 / 4
=> 6.75 ms
Average Turn Around Time:

Turn around time = Finished Time – Arrival Time

P1 = 3 – 0 = 3
P2 = 8 – 0 = 8
P3 = 16 – 0 = 16
P4 = 26 – 0 = 26

Average Turn around Time = 3 + 8 + 16 + 26 / 4

= 53 / 4
=> 13.25ms
 Average Waiting Time = 6.75
Average Turn around Time = 13.25

Pros:

 Moves a shorter process for execution before a longer process

 Having Least Average waiting time and Turn around time

Cons:

 The real difficulty of the SJF algorithm is knowing the

length of the next cpu Burst.( Request)
Shortest Job First Scheduling

• Example: Process Arrival Time Burst Time

P1 0 7
P2 2 4
P3 4 1
P4 5 4
• Non preemptive SJF
Average waiting time = (0 + 6 + 3 + 7)/4 = 4
P1 P3 P2 P4

0 2 4 5 7 8 12 16
P1‘s wating time = 0
P1(7)
P2(4) P2‘s wating time = 6
P3‘s wating time = 3
P3(1)
P4‘s wating time = 7
P4(4)
 Shortest Remaining Time First [SRTF]

 Policy => Preemptive Scheduling

 Scheduler compare the remaining time of executing process & new process

 Scheduler always selects the process that has Shortest Remaining Time
EXAMPLE 1: (preemptive)

• Process Name Arrival Time Service Time

1 0 8

2 1 4

3 2 9

4 3 5
Example 1 Conti….
•

Avg Waiting time (( 10-1)+(1-1)+(17-2)+(5-3))/4=6.5

Preemptive SJF
• Process Arrival Time Burst Time
P1 0.0 7
P2 2.0 4
P3 4.0 1
P4 5.0 4
• SJF (preemptive)

P1 P2 P3 P2 P4 P1

0 2 4 5 7 11 16

• Average waiting time = (9 + 1 + 0 +2)/4

-3
 EXAMPLE - 3

Arrival Time Process CPU Time (or) Burst Time

3
0 P1
6
2 P2
4
4 P3
5
6 P4
2
8 P5

P1 P2 P3 P5 P2 P4
0 3 4 8 10 15 20

Gantt Chart
 Determining Length of Next CPU Burst

• Can only estimate the length.

• Can be done by using the length of
previous CPU bursts, using exponential
averaging.
1. tn  actual lenght of nth CPU burst
2.  n 1  predicted value for the next CPU burst
3.  , 0    1
4. Define :

 n1   tn  1    n .
Prediction of the Length of the Next CPU Burst
Examples of Exponential Averaging
•  =0
—n+1 = n
—Recent history does not count.
•  =1
— n+1 = tn
—Only the actual last CPU burst counts.
• If we expand the formula, we get:
n+1 =  tn+(1 - )  tn -1 + …
+(1 -  )j  tn -1 + …
+(1 -  )n=1 tn 0
• Since both  and (1 - ) are less than or
equal to 1, each successive term has less
weight than its predecessor.
Priority Scheduling
• A priority number (integer) is associated with each process
• The CPU is allocated to the process with the highest priority
(smallest integer  highest priority).
—Preemptive
—nonpreemptive
• SJF is a priority scheduling where priority is the predicted
next CPU burst time.
• Problem  Starvation – low priority processes may never
execute.
• Solution  Aging – as time progresses increase the priority of
the process.
 Priority Scheduling

 Priority is associated with each process

 Scheduler always picks up the highest priority process for execution from
Ready Queue
 Priority scheduling can be either :

=> Preemptive If newly arrived process have higher priority

than running process >> Preempt the CPU

=> Non Preemptive Put the new process in Ready Queue

 EXAMPLE

Priority Process CPU Time (or) Burst Time

3 P1 5
2 P2 10
4 P3 8
1 P4 3

P4 P2 P1 P3
0 3 13 18 26

Gantt Chart
Priority Scheduling
Round Robin (RR)
• Each process gets a small unit of CPU time (time quantum),
usually 10-100 milliseconds. After this time has elapsed, the
process is preempted and added to the end of the ready queue.
• If there are n processes in the ready queue and the time
quantum is q, then each process gets 1/n of the CPU time in
chunks of at most q time units at once. No process waits more
than (n-1)q time units.
• Performance
—q large  FIFO
—q small  q must be large with respect to context switch,
otherwise overhead is too high.
EXAMPLE 1

Process CPU Time (or) Burst Time

P1
24
P2
3
P3
3

Time Quantum = 4 ms

P1 P2 P3 P1 P1 P1 P1 P1
0 4 7 10 14 18 22 26 30

Gantt Chart
Example 2:
Service
Process Arrival Time
• Time
1 0 3

2 2 6

3 4 4

4 6 5

5 8 2
TAT=CT-AT; WT=TAT-BT
•
Example 3 of RR with Time Quantum = 20

Process Burst Time

P1 53
P2 17
P3 68
P4 24
• The Gantt chart is:

P1 P2 P3 P4 P1 P3 P4 P1 P3 P3

0 20 37 57 77 97 117 121 134 154 162

• Typically, higher average turnaround than SJF, but

better response.
Multilevel Queue
• Ready queue is partitioned into separate queues:
foreground (interactive)
background (batch)
• Each queue has its own scheduling algorithm,
foreground – RR
background – FCFS
• Scheduling must be done between the queues.
—Fixed priority scheduling; (i.e., serve all from foreground
then from background). Possibility of starvation.
—Time slice – each queue gets a certain amount of CPU
time which it can schedule amongst its processes; i.e., 80%
to foreground in RR
—20% to background in FCFS
Multilevel Queue Scheduling
Multilevel Feedback Queue
• A process can move between the various
queues; aging can be implemented this
way.
• Multilevel-feedback-queue scheduler
defined by the following parameters:
—number of queues
—scheduling algorithms for each queue
—method used to determine when to upgrade a
process
—method used to determine when to demote a
process
—method used to determine which queue a
process will enter when that process needs
service
 Example of Multilevel Feedback Queue
• Three queues:
—Q0 – time quantum 8 milliseconds
—Q1 – time quantum 16 milliseconds
—Q2 – FCFS
• Scheduling
—A new job enters queue Q0 which is served
FCFS. When it gains CPU, job receives 8
milliseconds. If it does not finish in 8
milliseconds, job is moved to queue Q1.
—At Q1 job is again served FCFS and receives 16
additional milliseconds. If it still does not
complete, it is preempted and moved to queue
Q2.
Multilevel Feedback Queues
Multiple-Processor Scheduling
• CPU scheduling more complex when multiple CPUs are
available.
• Homogeneous processors within a multiprocessor.
• Load sharing
• Asymmetric multiprocessing – only one processor accesses the
system data structures, alleviating the need for data sharing.
Real-Time Scheduling
• Hard real-time systems – required to complete a critical task
within a guaranteed amount of time.
• Soft real-time computing – requires that critical processes
receive priority over less fortunate ones.
Process Synchronization
• Background
• The Critical-Section Problem
• Synchronization Hardware
• Semaphores
• Classical Problems of Synchronization
• Critical Regions
• Monitors
Background
• Concurrent access to shared data may result in data
inconsistency.
• Maintaining data consistency requires mechanisms to ensure
the orderly execution of cooperating processes.
• Shared-memory solution to bounded-buffer problem allows at
most n – 1 items in buffer at the same time. A solution, where
all N buffers are used is not simple.
—Suppose that we modify the producer-consumer code by
adding a variable counter, initialized to 0 and incremented
each time a new item is added to the buffer
Bounded-Buffer

• Shared data

#define BUFFER_SIZE 10
typedef struct {
...
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
int counter = 0;
Bounded-Buffer
• Producer process

item nextProduced;

while (1) {
while (counter == BUFFER_SIZE)
; /* do nothing */
buffer[in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
Bounded-Buffer
• Consumer process

item nextConsumed;

while (1) {
while (counter == 0)
; /* do nothing */
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
}
Bounded Buffer
• The statements

counter++;
counter--;

must be performed atomically.

• Atomic operation means an operation that

completes in its entirety without
interruption.
Bounded Buffer
• If both the producer and consumer attempt to update the
buffer concurrently, the assembly language statements may
get interleaved.

• Interleaving depends upon how the producer and consumer

processes are scheduled.
Bounded Buffer
• Assume counter is initially 5. One interleaving of statements
is:

producer: register1 = counter (register1 = 5)

producer: register1 = register1 + 1 (register1 = 6)
consumer: register2 = counter (register2 = 5)
consumer: register2 = register2 – 1 (register2 = 4)
producer: counter = register1 (counter = 6)
consumer: counter = register2 (counter = 4)

• The value of count may be either 4 or 6, where the correct

result should be 5.
Race Condition
• Race condition: The situation where several processes
access – and manipulate shared data concurrently. The final
value of the shared data depends upon which process finishes
last.

• To prevent race conditions, concurrent processes must be

synchronized.
The Critical-Section Problem

• n processes all competing to use some shared data

• Each process has a code segment, called critical
section, in which the shared data is accessed.
• Problem – ensure that when one process is
executing in its critical section, no other process is
allowed to execute in its critical section.
Solution to Critical-Section Problem
1. Mutual Exclusion. If process Pi is executing in
its critical section, then no other processes can be
executing in their critical sections.
2. Progress. If no process is executing in its critical section
and there exist some processes that wish to enter their critical
section, then the selection of the processes that will enter the
critical section next cannot be postponed indefinitely.
3. Bounded Waiting. A bound must exist on the number of
times that other processes are allowed to enter their critical
sections after a process has made a request to enter its critical
section and before that request is granted.
 Assume that each process executes at a nonzero speed
No assumption concerning relative speed of the n
processes.
Initial Attempts to Solve Problem
• Only 2 processes, P0 and P1
• General structure of process Pi (other process Pj)
do {
entry section
critical section
exit section
reminder section
} while (1);
• Processes may share some common variables to synchronize
their actions.
Sections of a Program
• Entry Section: It is part of the process which
decides the entry of a particular process.
• Critical Section: This part allows one process to
enter and modify the shared variable.
• Exit Section: Exit section allows the other process
that are waiting in the Entry Section, to enter into
the Critical Sections. It also checks that a process
that finished its execution should be removed
through this Section.
• Remainder Section: All other parts of the Code,
which is not in Critical, Entry, and Exit Section, are
known as the Remainder Section.
 Algorithm 1

• Shared variables: Process Pj

— int turn;
initially turn = 0
Do
— turn - i  Pi can enter its critical section
{
• Process Pi while (turn ! = j) ;
do {
critical section
while (turn != i) ;/* Do Skip */
critical section
turn = i;
turn = j; remainder section
reminder section } while (1);
} while (1);
• Satisfies mutual exclusion, but not progress
Algorithm 2

• Shared variables
—boolean flag[2];
initially flag [0] = flag [1] = false.
—flag [i] = true  Pi ready to enter its critical section
• Process Pi
do {
flag[i] := true;
while (flag[j]) ; critical
section
flag [i] = false;
remainder section
} while (1);
• Satisfies mutual exclusion, but not progress requirement.
Algorithm 3 (Peterson’s)

• Combined shared variables of algorithms 1 and 2.

• Process Pi
do {
flag [i]:= true;
turn = j;
while (flag [j] && turn = j) ;
critical section
flag [i] = false;
remainder section
} while (1);
• Meets all three requirements; solves the critical-
section problem for two processes.
Bakery Algorithm

Critical section for n processes

• Before entering its critical section, process receives a number.

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

Applications:
Bakeries, Ice-cream stores, Deli counters and Motor-Registries
etc:
Bakery Algorithm
• Notation < lexicographical order (ticket #, process id #)
— (a,b) < c,d) if a < c or if a = c and b < d
— max (a0,…, an-1) is a number, k, such that k  ai for i - 0,
…, n – 1
• Shared data
boolean choosing[n];
int number[n];
Data structures are initialized to false and 0 respectively
Bakery Algorithm

do {
choosing[i] = true;
number[i] = max(number[0], number[1], …, number [n – 1])
+1;
choosing[i] = false;
for (j = 0; j < n; j++) {
while (choosing[j]) ;
while ((number[j] != 0) && (number[j,j] <
number[i,i])) ;
}
critical section
number[i] = 0;
remainder section
} while (1);
Synchronization Hardware
• Test and modify the content of a word atomically
.
boolean TestAndSet(boolean &target) {
boolean rv = target;
target = true;

return rv;
}
Mutual Exclusion with Test-and-Set
• Shared data:
boolean lock = false;

• Process Pi
do {
while (TestAndSet(lock)) ;
critical section
lock = false;
remainder section
}
Synchronization Hardware
• Atomically swap two variables.

void Swap(boolean &a, boolean &b) {

boolean temp = a;
a = b;
b = temp;
}
Mutual Exclusion with Swap
• Shared data (initialized to false):
boolean lock;
boolean waiting[n];

• Process Pi
do {
key = true;
while (key == true)
Swap(lock,key);
critical section
lock = false;
remainder section
}
Hardware Mutual
Exclusion: Advantages

• Applicable to any number of processes on either a single

processor or multiple processors sharing main memory
• It is simple and therefore easy to verify
• It can be used to support multiple critical sections
Hardware Mutual
Exclusion: Disadvantages

• Busy-waiting consumes processor time

• Starvation is possible when a process leaves a critical section
and more than one process is waiting.
— Some process could indefinitely be denied access.
• Deadlock is possible
Semaphores
• Synchronization tool that does not require busy waiting.
• Semaphore S – integer variable
• can only be accessed via two indivisible (atomic)
operations
P: wait (S):
while S 0 do no-op;
S--;

V: signal (S):
S++;
Semaphore

• Fundamental principle of this design mechanism:

Two or more processes can cooperate by means of simple signals,

such that a process can be forced to stop at a specified place
until it has received a specific signal.
Semaphore

• Semaphore:
— An integer value used for signalling among processes.
• Only three operations may be performed on a semaphore, all
of which are atomic:
— initialize,
— Decrement (semWait)
— increment. (semSignal)
 Critical Section of n Processes

• Shared data:
semaphore mutex; //initially mutex = 1

• Process Pi:
do {
wait(mutex); //wait (S):
//P:while S 0 do no-op //
S--;
critical section
signal(mutex);

V: signal (S):
//S++;
remainder section
} while (1

problem for real multiprogramming systems ( Due to

busy waiting )
Semaphore Implementation( To avoid Busy
waiting Problem)
• Define a semaphore as a record
typedef struct {
int value;
struct process *L;
} semaphore;

• Assume two simple operations:

— block suspends the process that invokes it.
— wakeup(P) resumes the execution of a
blocked process P.
Implementation ( To avoid Busy waiting
Problem)

• Semaphore operations now defined as

wait(S):
S.value--;
if (S.value < 0) {
add this process to S.L;
block;
}

signal(S):
S.value++;
if (S.value <= 0) {
remove a process P from S.L;
wakeup(P);
}
 Semaphore as a General Synchronization Tool

• Execute B in Pj only after A executed in Pi

• Use semaphore flag initialized to 0
• Code:
Pi Pj
 
A wait(flag)
signal(flag) B
Deadlock and Starvation
• Deadlock – two or more processes are waiting indefinitely
for an event that can be caused by only one of the waiting
processes.
• Let S and Q be two semaphores initialized to 1
P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
 
signal(S); signal(Q);
signal(Q) signal(S);
• Starvation – indefinite blocking. A process may never be
removed from the semaphore queue in which it is suspended.
Two Types of Semaphores
• Counting semaphore – integer value
can range over an unrestricted domain.
• Binary semaphore – integer value can
range only between 0 and 1; can be
simpler to implement.
• Can implement a counting semaphore S
as a binary semaphore.
 Implementing S as a Binary Semaphore

• Data structures:
binary-semaphore S1, S2;
int C:
• Initialization:
S1 = 1
S2 = 0
C = initial value of semaphore S
Implementing S
• wait operation
wait(S1);
C--;
if (C < 0) {
signal(S1);
wait(S2);
}
signal(S1);

• signal operation
wait(S1);
C ++;
if (C <= 0)
signal(S2);
else
signal(S1);
 Classical Problems of Synchronization

• Bounded-Buffer Problem

• Readers and Writers Problem

• Dining-Philosophers Problem
Bounded-Buffer Problem
• Shared data

semaphore full, empty, mutex;

Initially:

full = 0, empty = n, mutex = 1

Bounded-Buffer Problem Producer Process

do {
…
produce an item in nextp
…
wait(empty);
wait(mutex);
…
add nextp to buffer
…
signal(mutex);
signal(full);
} while (1);
Bounded-Buffer Problem Consumer Process

do {
wait(full)
wait(mutex);
…
remove an item from buffer to nextc
…
signal(mutex);
signal(empty);
…
consume the item in nextc
…
} while (1);
Readers-Writers Problem
• S hared data

semaphore mutex, wrt;

Initially

mutex = 1, wrt = 1, readcount = 0

Readers-Writers Problem Writer Process
wait(wrt);
…
writing is performed
…
signal(wrt);
Readers-Writers Problem Reader Process

wait(mutex);
readcount++;
if (readcount == 1)
wait(wrt);
signal(mutex);
…
reading is performed
…
wait(mutex);
readcount--;
if (readcount == 0)
signal(wrt);
signal(mutex):
Dining-Philosophers Problem

• Shared data
semaphore chopstick[5];
Initially all values are 1
Dining Philosopher’s Problem (Dijkstra ’71)
 Dining Philosophers…

• Philosophers eat/think
• Eating needs 2 forks
• Pick one fork at a time
• How to prevent deadlock
Dining-Philosophers Problem

• Philosopher i:
do {
wait(chopstick[i])
wait(chopstick[(i+1) % 5])
…
eat
…
signal(chopstick[i]);
signal(chopstick[(i+1) % 5]);
…
think
…
} while (1);
Dining Philosophers

Solution to dining philosophers problem (part 1)

Dining Philosophers

Solution to dining philosophers problem (part 2)

Critical Regions
• High-level synchronization construct
• A shared variable v of type T, is declared as:
v: shared T
• Variable v accessed only inside statement
region v when B do S

where B is a boolean expression.

• While statement S is being executed, no other

process can access variable v.
Critical Regions
• Regions referring to the same shared variable exclude each
other in time.

• When a process tries to execute the region statement, the

Boolean expression B is evaluated. If B is true, statement S is
executed. If it is false, the process is delayed until B becomes
true and no other process is in the region associated with v.
Example – Bounded Buffer
• Shared data:

struct buffer {
int pool[n];
int count, in, out;
}
Bounded Buffer Producer Process
• Producer process inserts nextp into the shared
buffer

region buffer when( count < n) {

pool[in] = nextp;
in:= (in+1) % n;
count++;
}
Bounded Buffer Consumer Process
• Consumer process removes an item from the shared
buffer and puts it in nextc

region buffer when (count > 0) {

nextc = pool[out];
out = (out+1) % n;
count--;
}
 Implementation region x when B do S

• Associate with the shared variable x, the following variables:

semaphore mutex, first-delay, second-delay;
int first-count, second-count;

• Mutually exclusive access to the critical section is provided

by mutex.

• If a process cannot enter the critical section because the

Boolean expression B is false, it initially waits on the first-
delay semaphore; moved to the second-delay semaphore
before it is allowed to reevaluate B.
Implementation
• Keep track of the number of processes waiting on first-delay
and second-delay, with first-count and second-count
respectively.

• The algorithm assumes a FIFO ordering in the queuing of

processes for a semaphore.

• For an arbitrary queuing discipline, a more complicated

implementation is required.
Monitors
• High-level synchronization construct that allows the safe sharing of an
abstract data type among concurrent processes.

monitor monitor-name
{
shared variable declarations
procedure body P1 (…) {
...
}
procedure body P2 (…) {
...
}
procedure body Pn (…) {
...
}
{
initialization code
}
}
Monitors
• To allow a process to wait within the monitor, a condition
variable must be declared, as
condition x, y;
• Condition variable can only be used with the operations wait and
signal.
— The operation
x.wait();
means that the process invoking this operation is suspended until
another process invokes
x.signal();
— The x.signal operation resumes exactly one suspended process. If
no process is suspended, then the signal operation has no effect.
Schematic View of a Monitor
Monitor With Condition Variables
Dining Philosophers Example
monitor dp
{
enum {thinking, hungry, eating} state[5];
condition self[5];
void pickup(int i) // following slides
void putdown(int i) // following slides
void test(int i) // following slides
void init() {
for (int i = 0; i < 5; i++)
state[i] = thinking;
}
}
Dining Philosophers

void pickup(int i) {
state[i] = hungry;
test[i];
if (state[i] != eating)
self[i].wait();
}

void putdown(int i) {
state[i] = thinking;
// test left and right neighbors
test((i+4) % 5);
test((i+1) % 5);
}
Dining Philosophers

void test(int i) {
if ( (state[(I + 4) % 5] != eating) &&
(state[i] == hungry) &&
(state[(i + 1) % 5] != eating)) {
state[i] = eating;
self[i].signal();
}
}
Monitor Implementation Using Semaphores

• Variables
semaphore mutex; // (initially =
1)
semaphore next; // (initially =
0)
int next-count = 0;

• Each external procedure F will be

replaced by
wait(mutex);
…
body of F;
…
if (next-count > 0)
signal(next)
else
Monitor Implementation
• For each condition variable x, we have:
semaphore x-sem; // (initially = 0)
int x-count = 0;

• The operation x.wait can be implemented as:

x-count++;
if (next-count > 0)
signal(next);
else
signal(mutex);
wait(x-sem);
x-count--;
Monitor Implementation
• The operation x.signal can be implemented as:

if (x-count > 0) {
next-count++;
signal(x-sem);
wait(next);
next-count--;
}
Monitor Implementation
• Conditional-wait construct: x.wait(c);
— c – integer expression evaluated when the wait
operation is executed.
— value of c (a priority number) stored with the
name of the process that is suspended.
— when x.signal is executed, process with smallest
associated priority number is resumed next.
• Check two conditions to establish
correctness of system:
— User processes must always make their calls on
the monitor in a correct sequence.
— Must ensure that an uncooperative process does not
ignore the mutual-exclusion gateway provided by the
monitor, and try to access the shared resource directly,
without using the access protocols.
Deadlocks
• System Model
• Deadlock Characterization
• Methods for Handling Deadlocks
• Deadlock Prevention
• Deadlock Avoidance
• Deadlock Detection
• Recovery from Deadlock
• Combined Approach to Deadlock Handling
The Deadlock Problem
• A set of blocked processes each holding a resource and
waiting to acquire a resource held by another process in the
set.
• Example
—System has 2 tape drives.
—P1 and P2 each hold one tape drive and each needs another
one.
• Example
—semaphores A and B, initialized to 1

P0 P1
wait (A); wait(B)
wait (B); wait(A)
Bridge Crossing Example

• Traffic only in one direction.

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

I need I need
quad C quad B
and B and C

I need
I need quad A
quad D and B
and A
Actual Deadlock

HALT HALT
until D is until C is
free free

HALT
HALT until B is
until A is free
free
System Model
• Resource types R1, R2, . . ., Rm
CPU cycles, memory space, I/O devices
• Each resource type Ri has Wi instances.
• Each process utilizes a resource as
follows:
—request
—use
—release
Resource Categories

Two general categories of resources:

• Reusable
—can be safely used by only one process at a
time and is not depleted by that use.
• Consumable
—one that can be created (produced) and
destroyed (consumed).
Reusable Resources

• Such as:
—Processors, I/O channels, main and secondary
memory, devices, and data structures such as
files, databases, and semaphores
• Deadlock occurs if each process holds one
resource and requests the other
Example of
Reuse Deadlock

• Consider two processes that compete for

exclusive access to a disk file D and a tape
drive T.
• Deadlock occurs if each process holds one
resource and requests the other.
Example 2:
Memory Request

• Space is available for allocation of

200Kbytes, and the following sequence of
events occur
P1 P2

Request. 80
. . Kbytes; ...
Request 70 Kbytes;

... ...
Request 80 Kbytes;
Request 60 Kbytes;

• Deadlock occurs if both processes

progress to their second request
Consumable Resources

• Such as Interrupts, signals, messages,

and information in I/O buffers
• Deadlock may occur if a Receive message
is blocking
• May take a rare combination of events to
cause deadlock
Example of Deadlock

• Consider a pair of processes, in which

each process attempts to receive a
message from the other process and then
send a message to the other process
Deadlock Characterization
Deadlock can arise if four conditions hold simultaneously.

• Mutual exclusion: only one process at a time can use

a resource.
• Hold and wait: a process holding at least one
resource is waiting to acquire additional resources held
by other processes.
• No preemption: a resource can be released only voluntarily by
the process holding it, after that process has completed its task.
• Circular wait: there exists a set {P0, P1, …, P0} of waiting
processes 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 P0 is waiting for a resource that is held by P0.
Resource-Allocation Graph

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

• V is partitioned into two types:

—P = {P1, P2, …, Pn}, the set consisting of
all the processes in the system.

—R = {R1, R2, …, Rm}, the set consisting of

all resource types in the system.
• request edge – directed edge Pi  Rj
• assignment edge – directed edge Rj 
Pi
Resource-Allocation Graph (Cont.)

• Process

• Resource Type with 4 instances

Pi

Rj
• Pi requests instance of Rj

Pi
Rj

• Pi is holding an instance of Rj
Resource Allocation
Graphs

• Directed graph that depicts a state of the

system of resources and processes
Example of a Resource Allocation Graph
Resource Allocation Graph With A Deadlock
Resource Allocation Graph With A Cycle But No Deadlock
Resource Allocation
Graphs
Resource Allocation
Graphs of deadlock
Basic Facts
• If graph contains no cycles  no
deadlock.

• If graph contains a cycle 

—if only one instance per resource type, then
deadlock.
—if several instances per resource type,
possibility of deadlock.
Methods for Handling Deadlocks
• Ensure that the system will never enter a
deadlock state.( Protocol for Deadlock
prevention or a deadlock Avoidance )
• Allow the system to enter a deadlock
state, Detect it and then recover.

• Ignore the problem (Ostrich Technique )and pretend

that deadlocks never occur in the system; used by most
operating systems, including UNIX.
Deadlock Prevention Strategy

• Design a system in such a way that the

possibility of deadlock is excluded.
• Two main methods
— Indirect – prevent all three of the necessary
conditions occurring at once
— Direct – prevent circular waits
Deadlock Prevention
Restrain the ways request can be made. ( Ensure that at least
one of these conditions cannot hold )

• Mutual Exclusion – not required for

sharable resources; must hold for nonsharable resources.

• Hold and Wait – must guarantee that

whenever a process requests a resource, it does not hold any
other resources.
— Require process to request and be allocated all its resources
before it begins execution, or allow process to request
resources only when the process has none.
— Low resource utilization; starvation possible.
Deadlock Prevention (Cont.)
• No Preemption –
—If a process that is holding some resources requests
another resource that cannot be immediately allocated to it,
then all resources currently being held are released.
—Preempted resources are added to the list of resources for
which the process is waiting.
—Process will be restarted only when it can regain its old
resources, as well as the new ones that it is requesting.

• Circular Wait – impose a total ordering of all

resource types, and require that each process requests
resources in an increasing order of enumeration.
Deadlock Avoidance
Requires that the system has some additional a priori information
available.
• Simplest and most useful model requires that each
process declare the maximum number of resources of
each type that it may need.

• The deadlock-avoidance algorithm dynamically

examines the resource-allocation state to ensure that
there can never be a circular-wait condition.

• Resource-allocation state is defined by the number

of available and allocated resources, and the
maximum demands of the processes.
Safe State
• When a process requests an available resource,
system must decide if immediate allocation leaves the
system in a safe state.

• System is in safe state if there exists a safe sequence

of all processes.

• Sequence <P1, P2, …, Pn> is safe if for each Pi, the

resources that Pi can still request can be satisfied by
currently available resources + resources held by all
the Pj, with j<I.
— If Pi resource needs are not immediately available, then Pi
can wait until all Pj have finished.
— When Pj is finished, Pi can obtain needed resources,
execute, return allocated resources, and terminate.
— When Pi terminates, Pi+1 can obtain its needed resources,
and so on.
Basic Facts
• If a system is in safe state  no deadlocks.

• If a system is in unsafe state  possibility of deadlock.

• Avoidance  ensure that a system will never enter an unsafe

state.
Safe, Unsafe , Deadlock State
Resource-Allocation Graph Algorithm
• Claim edge Pi  Rj indicated that process Pj may request
resource Rj; represented by a dashed line.

• Claim edge converts to request edge when a process requests

a resource.

• When a resource is released by a process, assignment edge

reconverts to a claim edge.

• Resources must be claimed a priori in the system.

Resource-Allocation Graph For Deadlock Avoidance
Unsafe State In Resource-Allocation Graph
Two Approaches to Deadlock Avoidance

• Process Initiation Denial

— Do not start a process if its demands might
lead to deadlock

• Resource Allocation Denial

— Do not grant an incremental resource request
to a process if this allocation might lead to
deadlock
Process Initiation Denial

• A process is only started if the maximum

claim of all current processes plus those of
the new process can be met.
• Not optimal,
—Assumes the worst: that all processes will
make their maximum claims together.
Resource
Allocation Denial

• Referred to as the banker’s algorithm

—A strategy of resource allocation denial
• Consider a system with fixed number of
resources
—State of the system is the current allocation of
resources to process
—Safe state is where there is at least one
sequence that does not result in deadlock
—Unsafe state is a state that is not safe
Banker’s Algorithm
• Multiple instances.

• Each process must a priori claim maximum use.

• When a process requests a resource it may have to wait.

• When a process gets all its resources it must return them in

a finite amount of time.
Application:
• Banker's Algorithm name was chosen because this algorithm
could be used in banking system to ensure that bank should
not run out of cash (resources).
• So, bank never allocates its available cash in such a way that
it can no longer satisfy the needs of all its customers.
• Using Banker's algorithm Banks ensures that when
customers need cash (resources), algorithm will determine
whether allocation of cash will leave Bank in safe state or not.
• If it will cash are allocated, otherwise customer must wait
until some another customer deposit enough cash.
State of the current allocation of
resources

Resource = R = (R1, R2, … Rm) Total amount of each recourse on the

system
Available=V= (V1, V2, … Vm) Total amount of each resource not
allotted to any process
C11 C12 … C1m
C21 C22 … C2m
C31 C32 … C3m Cij = requirement of process i for
resource j
Claim = C = C41 C42 … C4m
…
Cn1 Cn2 … Cnm
A11 A12 … A1m
A21 A22 … A2m
A31 A32 … A3m Aij = current allocation to process i
for resource j
Allocation= A = A41 A42 … A4m
…
An1 An2 … Anm
 Determination of
Safe State ( Example: 1)
• A system consisting of four processes and three resources.
• Allocations are made to processors
• Is this a safe state?:

Resources
Amount of available
Existing after
Resources allocation
Can any of the 4 processes run to completion with resources available?
Process i

• Cij - Aij ≤ Vj, for all j

• This is not possible for P1,
— which has only 1 unit of R1 and requires 2 more units of
R1, 2 units of R2, and 2 units of R3.
• If we assign one unit of R3 to process P2,
— Then P2 has its maximum required resources allocated
and can run to completion and return resources to
‘available’ pool
After P2
runs to completion

• Can any of the remaining processes

can be completed?

Note P2 is
completed
After P1 completes
P3 Completes

Thus, the state

defined originally is
a safe state.
Determination of an
Unsafe State

This time
Suppose that
P1 makes the
request for
one additional
unit each of
R1 and R3.
Is this safe?
Deadlock Avoidance

• When a process makes a request for a set of resources,

— assume that the request is granted,
— Update the system state accordingly,
• Then determine if the result is a safe
state.
— If so, grant the request and,
— if not, block the process until it is safe to grant the request.
Deadlock Avoidance
Logic
Deadlock Avoidance
Logic
Deadlock Avoidance Advantages

• It is not necessary to preempt and

rollback processes, as in deadlock
detection,
• It is less restrictive than deadlock
prevention.
Deadlock Avoidance Restrictions

• Maximum resource requirement must be stated in advance

• Processes under consideration must be independent and with
no synchronization requirements
• There must be a fixed number of resources to allocate
• No process may exit while holding resources
 Data Structures for the Banker’s Algorithm

Let n = number of processes, and m = number of resources types.

• Available: Vector of length m. If available [j] = k,

there are k instances of resource type Rj available.
• Max: n x m matrix. If Max [i,j] = k, then process Pi may
request at most k instances of resource type Rj.
• Allocation: n x m matrix. If Allocation[i,j] = k then
Pi is currently allocated k instances of Rj.
• Need: n x m matrix. If Need[i,j] = k, then Pi may need k
more instances of Rj to complete its task.

Need [i,j] = Max[i,j] – Allocation [i,j].

Safety Algorithm
1. Let Work and Finish be vectors of length m and n, respectively. Initialize:
Work = Available
Finish [i] = false for i - 1,3, …, n.
2. Find and i such that both:
(a) Finish [i] = false
(b) Needi  Work
If no such i exists, go to step 4.
3. Work = Work + Allocationi
Finish[i] = true
go to step 2.
4. If Finish [i] == true for all i, then the system is in a safe state.
Resource-Request Algorithm for Process Pi

Request = request vector for process Pi. If Requesti [j] = k then

process Pi wants k instances of resource type Rj.
1. If Requesti  Needi go to step 2. Otherwise, raise error
condition, since process has exceeded its maximum claim.
2. If Requesti  Available, go to step 3. Otherwise Pi must
wait, since resources are not available.
3. Pretend to allocate requested resources to Pi by modifying
the state as follows:
Available = Available = Requesti;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;;
• If safe  the resources are allocated to Pi.
• If unsafe  Pi must wait, and the old resource-allocation
state is restored
Banker’s Algorithm
• 5 processes P0 through P4; 3 resource types A
(10 instances),
B (5instances, and C (7 instances).
• Snapshot at time T0:
Allocation Max Available
ABC ABC ABC
P0 0 1 0 7 5 3 3 3 2
P1 2 0 0 3 2 2
P2 3 0 2 9 0 2
P3 2 1 1 2 2 2
P4 0 0 2 4 3 3
Example (Cont.)

• The content of the matrix. Need is defined to be Max – Allocation.

Need
ABC
P0 7 4 3
P1 1 2 2
P2 6 0 0
P3 0 1 1
P4 4 3 1
• The system is in a safe state since the sequence < P1, P3, P4, P2, P0>
satisfies safety criteria.
Example P1 Request (1,0,2) (Cont.)

• Check that Request  Available (that is, (1,0,2)  (3,3,2)  true.

Allocation Need Available
ABC ABC ABC
P0 0 1 0 743 230
P1 3 0 2 020
P2 3 0 1 600
P3 2 1 1 011
P4 0 0 2 431
• Executing safety algorithm shows that sequence <P1, P3, P4, P0, P2>
satisfies safety requirement.
• Can request for (3,3,0) by P4 be granted?
• Can request for (0,2,0) by P0 be granted?
Deadlock Detection
• Allow system to enter deadlock state

• Detection algorithm

• Recovery scheme
 Single Instance of Each Resource
Type
• Maintain wait-for graph
— Nodes are processes.
— Pi  Pj if Pi is waiting for Pj.

• Periodically invoke an algorithm that searches for a cycle in the graph.

• An algorithm to detect a cycle in a graph requires an order of n2

operations, where n is the number of vertices in the graph.
Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph Corresponding wait-for graph

 Several Instances of a Resource Type

• Available: A vector of length m indicates the number of available

resources of each type.

• Allocation: An n x m matrix defines the number of resources

of each type currently allocated to each process.

• Request: An n x m matrix indicates the current request of each process.

If Request [ij] = k, then process Pi is requesting k more instances of resource
type. Rj.
Detection Algorithm
1. Let Work and Finish be vectors of length m and n,
respectively Initialize:
(a) Work = Available
(b) For i = 1,2, …, n, if Allocationi  0, then
Finish[i] = false;otherwise, Finish[i] = true.
2. Find an index i such that both:
(a) Finish[i] == false
(b) Requesti  Work

If no such i exists, go to step 4.

Detection Algorithm (Cont.)
3. Work = Work + Allocationi
Finish[i] = true
go to step 2.

4. If Finish[i] == false, for some i, 1  i  n, then the system is in

deadlock state. Moreover, if Finish[i] == false, then Pi is deadlocked.

Algorithm requires an order of O(m x n2) operations to detect whether

the system is in deadlocked state.
Example of Detection Algorithm
• Five processes P0 through P4; three resource types
A (7 instances), B (2 instances), and C (6 instances).
• Snapshot at time T0:
Allocation Request Available
ABC ABC ABC
P0 0 1 0 0 0 0 0 0 0
P1 2 0 0 2 0 2
P2 3 0 3 0 0 0
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2
• Sequence <P0, P2, P3, P1, P4> will result in Finish[i] = true
for all i.
Example (Cont.)
• P2 requests an additional instance of type C.
Request
ABC
P0 0 0 0
P1 2 0 1
P2 0 0 1
P3 1 0 0
P4 0 0 2
• State of system?
— Can reclaim resources held by process P0, but insufficient
resources to fulfill other processes; requests.
— Deadlock exists, consisting of processes P1, P2, P3, and
Detection-Algorithm Usage
• When, and how often, to invoke depends on:
— How often a deadlock is likely to occur?
— How many processes will need to be rolled back?
– one for each disjoint cycle

• If detection algorithm is invoked arbitrarily, there

may be many cycles in the resource graph and so we
would not be able to tell which of the many
deadlocked processes “caused” the deadlock.
 Recovery from Deadlock: Process Termination

• Abort all deadlocked processes.

• Abort one process at a time until the deadlock cycle is eliminated.

• In which order should we choose to abort?

— Priority of the process.
— How long process has computed, and how much longer
to completion.
— Resources the process has used.
— Resources process needs to complete.
— How many processes will need to be terminated.
— Is process interactive or batch?
 Recovery from Deadlock: Resource Preemption

• Selecting a victim – minimize cost.

• Rollback – return to some safe state, restart process for

that state.

• Starvation – same process may always be picked as

victim, include number of rollback in cost factor.
Deadlock Ignorance( Ostrich Technique)
•
Advantages and Disadvantages
Combined Approach to Deadlock Handling
• Combine the three basic approaches
— prevention
— avoidance
— detection
allowing the use of the optimal approach for each of
resources in the system.

• Partition resources into hierarchically ordered classes.

• Use most appropriate technique for handling deadlocks

within each class.
Traffic Deadlock for Exercise
Thank you