Chapter 6: CPU Scheduling and deadlock

1
 Chapter 6: CPU Scheduling and deadlock
Scheduling
 Basic Concepts of scheduling
 Scheduling Criteria
 Scheduling Algorithms
 Algorithm Evaluation
Deadlock
 Deadlock Characterization
 Methods for Handling Deadlocks
 Deadlock Prevention
 Deadlock Avoidance
 Deadlock Detection
 Recovery from Deadlock

2
 CPU Scheduling
In discussing process management and synchronization, we talked
about context switching among processes/threads on the ready queue
But we have glossed over the details of exactly which thread is
chosen from the ready queue
Making this decision is called scheduling

Scheduling is a task of selecting a process/thread from a ready

queue and letting it run on the CPU
 This is done by a scheduler also called dispatcher

Types of Scheduler
 Non-preemptive scheduler voluntarily cease to keep or claim; give up.

 Process remains scheduled until voluntarily relinquishes CPU

 Preemptive scheduler
 Process may be descheduled at any time
3
 When to schedule?

A new job starts

The running job exits
The running job is blocked
I/O interrupt (some processes will be ready)
Timer interrupt
 Every 10 milliseconds (Linux 2.4)
 Every 1 millisecond (Linux 2.6)

4
 Scheduling/Performance Criteria

CPU utilization – keep the CPU as busy as possible

Throughput – # of processes that complete their execution per
time unit
Turnaround time – The interval from the time of submission of a
process to the time of completion.
 Sum of the periods spent waiting to get into memory, waiting in the
ready queue, executing on the CPU, and doing 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)

6
 Gantt Chart

Illustrates how processes/jobs are scheduled over time on CPU

Example:

A B C
0 10 12 16
Time

9
SCHEDULING
ALGORITHMS

10
 First- Come, First-Served (FCFS) Scheduling

Jobs are executed on first come, first serve basis.

Easy to understand and implement.
Poor in performance as average wait time is high.

Process Burst 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

Waiting time for P1 = 0; P2 = 24; P3 = 27

Average waiting time: (0 + 24 + 27)/3 = 17

11
 FCFS Scheduling (Cont.)

Suppose that the processes arrive in the order:

P2 , P3 , P1
 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
 Drawback of FCFS- large avg waiting time if short process behind
long process. This is also called Convoy effect
 Note also that the FCFS scheduling algorithm is nonpreemptive.
 Troublesome for timesharing systems

12
 Shortest-Job-First (SJF) Scheduling

Associate with each process the length of its next CPU burst
 Use these lengths to schedule the process with the shortest time
SJF is optimal – gives minimum average waiting time for a
given set of processes if all arrives simultanously
 The difficulty is knowing the length of the next CPU request
 Could ask the user

13
 Example of SJF
ProcessArriva lBurst Time
P1 0.0 6
P2 2.0 8
P3 4.0 7
P4 5.0 3

SJF scheduling chart

P4 P1 P3 P2
0 3 9 16 24

Average waiting time = (3 + 16 + 9 + 0) / 4 = 7

14
 SJF is not always optimal
Is SJF optimal if not all the processes are available simultaneously?

What if both arrived simultaneously ?

P2 P1
0 2 12

P1 waiting time: 2-0=2 The average waiting time: (2+0)/2=1

P2 waiting time: 0-0=0 15
 Shortest-Remaining-Time-First

The SJF algorithm can be either

 preemptive or
 nonpreemptive.
a non pre-emptive SJF algorithm will allow the currently running
process to finish its CPU burst.
 The examples of SJF we saw earlier are non-preemptive
whereas A preemptive SJF algorithm will preempt the currently
executing process, if the newly arrived process may be shorter
than what is left of the currently executing process.

Preemptive SJF scheduling is sometimes called shortest-

remaining-time-first scheduling

16
 Example of Shortest-remaining-time-first
 Now we add the concepts of varying arrival times and preemption to the
analysis
ProcessAarri Arrival TimeT Burst Time
P1 0 8
P2 1 4
P3 2 9
P4 3 5
 Preemptive SJF Gantt Chart

P1 P2 P4 P1 P3
0 1 5 10 17 26
 Average waiting time =
 WT for P1: (0-0) + (10-1)=9 WT for P2= 1 – 1= 0
 WT for P3: 17 – 2= 15 WT for P4: 5-3= 2
 Therefore, the AWT : [(10-1)+(1-1)+(17-2)+5-3)]/4 = 26/4 = 6.5
 Exercise:
 What is AWT for nonprimitive SJF ?
17
 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

Problem  Starvation – low priority processes may never execute

Solution  Aging – as time progresses increase the priority of the

process

18
 Example of Priority Scheduling

ProcessAarri Burst TimeT Priority

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

Priority scheduling Gantt Chart

Average waiting time = 8.2

19
 Round Robin (RR)

Each process gets a small unit of CPU time (time quantum q),
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.
Timer interrupts every quantum to schedule next process

Performance
 q large  FIFO
 q small  q must be large with respect to context switch, otherwise
overhead is too high

20
Time Quantum and Context Switch Time

21
 Example of RR with Time Quantum = 4

Process Burst Time

P1 24
P2 3
P3 3
The Gantt chart is:

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

Typically, higher average turnaround than SJF, but better response

q should be large compared to context switch time
q usually 10ms to 100ms, context switch < 10 usec

22
 Multilevel Queue

Ready queue is partitioned into separate queues, eg:

 foreground (interactive)
 background (batch)
Process permanently in a given queue
Each queue has its own scheduling algorithm:
 foreground – RR
 background – FCFS
Scheduling must be done between the queues:
 Fixed priority preemptive 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;
 Like,
80% to foreground in RR
 20% to background in FCFS

23
Multilevel Queue Scheduling

SIIBS

24
 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 or demote a process
 method used to determine which queue a process will enter when that
process needs service

25
 Example of Multilevel Feedback Queue

Three queues:
 Q0 – RR with time quantum 8 milliseconds
 Q1 – RR 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

26
MULTIPROCESSOR
SCHEDULING
Affinity and Load balancing

27
 Multiple-Processor Scheduling
CPU scheduling becomes more complex when multiple CPUs are
Involved
Approaches to Multiple-processor scheduling
 Asymmetric multiprocessing, in which one processor is the master,
controlling all activities and running all kernel code, while the other runs
only user code.
 This approach is relatively simple, as there is no need to
share critical system data.
 Symmetric multiprocessing, SMP, where each processor schedules
its own jobs, either from a common ready queue or from separate
ready queues for each processor.
 Currently, most common ( XP, Solaris, Linux, etc …)

28
 Processor affinity wedaginet
Processors contain cache memory, which speeds up repeated
accesses to the same memory locations.
If a process were to switch from one processor to another each time it
got a time slice,
 the data in the cache ( for that process ) would have to be invalidated in
the 1st processor and
 the cache for the 2nd processor must be repopulated from main memory,
 thereby obviating the benefit of the cache.
Therefore SMP systems attempt to keep processes on the same
processor. This is called processor affinity.
 Soft affinity - the system attempts to keep processes on the same
processor but makes no guarantees. https://youtu.be/
4Hef8nxWuYU
 Hard affinity - a process specifies that it is not to be moved between
processors .E.g. Linux and some other Oses

29
 Multiple-Processor Scheduling – Load Balancing

Obviously an important goal in a multiprocessor system is

to balance the load between processors,
 Therefore, one processor won't be sitting idle while another is
overloaded.
Load balancing attempts to keep workload evenly
distributed
 Systems using a common ready queue are naturally self-
balancing, and do not need any special handling.
 However, systems maintaining separate ready queues for each
processor needs load balancing mechanisms.

31
Multiple-Processor Scheduling – Load Balancing
Load balancing can be achieved through:
 Push migration – periodic task checks load on each processor,
and if found pushes task from overloaded CPU to other CPUs
 Pull migration – idle processors pulls waiting task from busy
processor
 Push and pull migration are not mutually exclusive.
Note
 Load balancing works against Affinity
 Load balancing - Moving processes from CPU to CPU to
achieve load balancing
 Affinity - Keep processes to run on same processor, and
 if not carefully managed, the savings gained by balancing the system can
be lost in rebuilding caches.
One option is to only allow migration when imbalance
surpasses a given threshold.
32
REALTIME SCHEDULING
Rate Monotonic Scheduling
Earliest Deadline Scheduling

33
 Real-Time CPU Scheduling
Real-time OS present obvious
scheduling challenges as the time at
which tasks complete is crucial to their
performance. They are two types
1. Soft real-time systems – no
guarantee as to when critical real-time
process will be scheduled
 Degraded performance if their timing needs
cannot be met. Example: streaming video.
2. Hard real-time systems – task must
be serviced by its deadline
Two types of latencies affect
performance of RTS (Real time
systems)
1. Interrupt latency – time from arrival of interrupt to
start of routine that services interrupt
2. Dispatch latency – time for schedule to take
current process off CPU and switch to another

34
 Priority-based Scheduling
For real-time scheduling, scheduler must support preemptive, priority-
based scheduling
 But only guarantees soft real-time
For hard real-time, scheduler must also provide ability to meet
deadlines
Hard RTS are often characterized by tasks that must run at regular
periodic intervals
 Has processing time t, deadline d, period p
 0≤t≤d≤p

36
 Rate Monotonic Scheduling (RMS)
 The rate-monotonic scheduling algorithm uses pre-emptive scheduling
with static priorities.
 A priority is assigned based on the inverse of its period
 Shorter periods = higher priority;
 Longer periods = lower priority
 Example:- Assume we have 2 processes P1 and P2 with the following
characteristics
 P1 has p1=50, t1=20, and a deadline that matches its period (d1= 50 ).
 P2 has p2=100, t2=35, and d2= 100.
 The total CPU utilization time is 20 / 50 = 0.4 for P1, and 35 / 100 = 0.35 for P2,
or 0.75 ( 75% ) overall.
 P1 is assigned a higher priority than P2.

 What would happen if P2 were assigned a higher priority ?

37
 Missed Deadlines with Rate Monotonic Scheduling

Rate-monotonic scheduling is considered optimal

 Processes that cannot be scheduled with this algorithm cannot be
scheduled with any other static-priority scheduling algorithm either.
There are, however, some sets of processes that cannot be scheduled
with static priorities.
 For example, supposing that P1 =50, T1 = 25, P2 = 80, T2 = 35, and the
deadlines match the periods.
 Overall CPU usage is 25/50 = 0.5 for P1, 35 / 80 =0.44 for P2 == ( 94% )
overall, indicating it should be possible to schedule the processes.
 With RMS, P1 goes first, and completes its first burst at time 25.
 P2 goes next, and completes 25 out of its 35 time units before it gets pre-
empted by P1 at time 50.
 P1 completes its second burst at 75, and then P2 completes its last 10 time
units at time 85, missing its deadline of 80 by 5 time units

38
 RMS cont...

 The limitation of this algorithm is that CPU utilization is bounded,

and it is not always possible fully to maximize utilization of CPU
resources.
 The worst-case CPU utilization for scheduling N processes
under this algorithm is N * ( 2(1/N) - 1 ),
 Which is 100% for a single process but it falls to approximately
69% as the number of processes approaches infinity.
 With two processes , CPU utilization is bounded at about 83%.

 CPU utilization of P1 and P2 on slide 37 is 75%, i.e. it is under the

bound of 83% and , therefore, RMS algorithm is guaranteed to
schedule with no process missing its deadline.

 On the other hand, since CPU utilization of P1 and P2 on the

previous slide is 94%, RMS algorithm cannot guarantee that they
can be scheduled so that they meet their deadlines.
39
 Earliest Deadline First Scheduling (EDF)

EDF scheduling dynamically assigns priorities according to deadline.

 the earlier the deadline, the higher the priority;
 the later the deadline, the lower the priority
Example:- consider processes on slide 38.
 Recall that P1 has values of p1 =50 and t1 =25 and that P2 has values of
p2=80 and t2=35.

Theoretically, EDF can schedule processes so that each process can

meet its deadline requirements and CPU utilization will be 100
percent.
In practice, however, it is impossible to achieve this level of CPU
utilization due to the cost of context switching between processes
and interrupt handling.
40
 Algorithm Evaluation
How to select CPU-scheduling algorithm for an OS?
Determine criteria, then evaluate algorithms

1. Deterministic modeling
 Type of analytic evaluation
 Takes a particular predetermined workload and defines the
performance of each algorithm for that workload
Consider 5 processes arriving at time 0:

42
 Deterministic Evaluation
For each algorithm, calculate minimum average waiting time
Simple and fast, but requires exact numbers for input, applies only
to those inputs
FCS is 28ms:

Non-preemptive SFJ is 13ms:

RR is 23ms:

43
 Queueing Models

Specific process data is often not available, particularly for future

times.

However a study of historical performance can often produce

statistical descriptions of certain important parameters, such as
 the rate at which new processes arrive,
 the ratio of CPU bursts to I/O times,
 the distribution of CPU burst times and I/O burst times, etc.

Given those probability distributions and some mathematical

formulas, it is possible to calculate certain performance
characteristics of individual waiting queues.

44
 Little’s Formula n=lambda*W

n = average queue length

W = average waiting time in queue
λ = average arrival rate into queue
Little’s law – in steady state, processes leaving queue must
equal processes arriving, thus:
n=λxW
 Valid for any scheduling algorithm and arrival distribution
For example,
 if on average 7 processes arrive per second, and
 normally 14 processes in queue, then
 What is the average waiting time ?
W= n / λ --- > 14/7
 Therefore, average wait time per process = 2 seconds

45
 Simulations

Simulations are more accurate

 Programmed model of computer system
 Gather statistics indicating algorithm performance
 Data to drive simulation gathered via
 Random number generator according to probabilities
 Distributions defined mathematically or empirically
 Trace tapes record sequences of real events in real systems

46
Evaluation of CPU Schedulers by Simulation

47
 Implementation

 Even simulations have limited accuracy

 Just implement new scheduler and test in real systems
 High cost, high risk
 Environments vary
 Most flexible schedulers can be modified per-site or per-system
 Or provide APIs to modify priorities

48
 Scheduling Summary

Scheduler (dispatcher) is the module that gets invoked when a

context switch needs to happen
Scheduling algorithm determines which process runs, where
processes are placed on queues
Many potential goals of scheduling algorithms
 Utilization, throughput, wait time, response time, etc.
Various algorithms to meet these goals
 FCFS/FIFO, SJF, Priority, RR
Can combine algorithms
 Multiple-level feedback queues
Issues in multiprocessor scheduling
 Affinity, load balancing
Real time scheduling
 RMS, EDS
The goodness of scheduling algithms can be evaluated using
 determnistic, queue modeling, simulation and implmentation

49
Deadlocks
 What is the goal?

To develop a description of deadlocks, which prevent sets of

concurrent processes from completing their tasks
To present a number of different methods for preventing or
avoiding deadlocks in a computer system

51
 System Model
System consists of resources
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
If request can not be granted:
– The requesting process can block
– The requesting process can be returned an error code and it can then try
requesting the resource again.

52
 Formal definition of deadlock
A set of processes is deadlocked if each process in the set is waiting
for an event that only another process in the set can cause
 Usually the event is release of a currently held resource
When deadlock occurs None of the processes can …
 Run
 release resources
 be awakened

53
 Questions
Is deadlock the same as starvation (or infinitely postponed)?
Can you mention some Real life analogies such as:
 “You take the monitor, I grab the keyboard”
 Cars in intersection

54
 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, …, Pn} 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 Pn is waiting for a resource that is
held by P0.

55
 Resource-Allocation Graph
Is a directed graph used to model deadlock
Is having a set of vertices V and a set of edges E.
Vertices (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
Edge (E) are of two types
 request edge – directed edge Pi  Rj
 assignment edge – directed edge Rj  Pi

56
 Resource-Allocation Graph (Cont.)

Process

Resource Type with 4 instances

Pi requests instance of Rj
Pi
Rj
Pi is holding an instance of Rj

Pi
Rj

57
 Example of a Resource Allocation Graph

The following RAG 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}

 One instance of R1
 Two instances of R2
 One instance of R3
 Three instance of R4
 P1 holds one instance of R2 and is
waiting for an instance of R1
 P2 holds one instance of R1, one
instance of R2, and is waiting for
an instance of R3
 P3 is holds one instance of R3
58
Resource Allocation Graph With A Deadlock

There exist two cycles

 P1→R1→P2→R3→P3→R2→P1
 P2→R3→P3→R2→P2
Process involved in the cycle are at the risk of being deadlocked. i.e
P1, P2, P3

59
 Graph With A Cycle But No Deadlock
Here also we have a cycle
 P1→R1→P3→R2→P1
But no deadlock since
 Process P4 may release its instance of resource type R2 and that
resource can then be allocated to P3, breaking the cycle.
 Process P2 may release its instance of resource type R1 and that
resource can then be allocated to P1, breaking the cycle.

60
 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

61
 Methods for Handling Deadlocks

Just ignore the problem altogether

 Pretend as if there is no deadlock optimistic approach

Ensure that the system will never enter a deadlock state:

 Deadlock prevention
 negating one of the four necessary condition
 Deadlock avoidance
 careful resource allocation
Allow the system to enter a deadlock state and then recover

62
 Approach 1: The ostrich algorithm
Pretend there is no problem
Reasonable if
– deadlocks occur very rarely
– cost of prevention is high
Example of “cost”, only one process runs at a time(No Parallilism)
UNIX and Windows takes this approach for some of the more complex
resource relationships to manage

63
 Approach 2:Deadlock Prevention
Deadlocks can be prevented by preventing at least one of the four
required conditions for deadlock to happen

Just invalidate one of the four necessary conditions for deadlock:

 Mutual exclusion
 Hold and wait
 No pre-emption
 Circular Wait

This approach tries to handle deadlock by restraining the ways

request can be made

64
 Cont’d...
Attacking mutual exclusion condition(Let processes to use
resources simultaneously)
 Because Mutex is not required for sharable resources (e.g., read-only files);
 But, doing so may result in race condition
 Not feasible in general (Some devices/resource are intrinsically not
shareable.)
 printer, tape
Attacking Hold and Wait condition– Require process to request and be
allocated all its resources before it begins execution, or
 a process never has to wait for what it needs
Issues
 may not know required resources at start of run
 not always possible
Another alternative,
 allow process to request resources only when the process has none
allocated to it.

65
 Deadlock Prevention (Cont.)

Attacking No Preemption condition–

 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
Attacking Circular Wait condition – impose a total ordering of all
resource types, and require that each process requests resources in
an increasing order of enumeration
 In other words, in order to request resource Rj, a process must first
release all Ri such that i <= j.

One big challenge in this scheme is determining the relative

ordering of the different resources

66
 Example : Assume we have plotter and scanner resources
and they are numerically numbered as 1 and 2. The
following RAG shows a deadlock situation

The displayed deadlock cannot happen

– If A requires 1, it must acquire it
before acquiring 2
– Note: If B has 1, all higher numbered
resources must be free or
held by processes who doesn’t need 1

• Resources ordering is a common

technique in practice!!!!!

67
Summary of approaches to deadlock prevention

Condition Approach
• Mutual Exclusion • Not feasible
• Hold and Wait • Request resources initially
• No Preemption • Take resources away
• Circular Wait • Order resources numerically

69
 Approach 3. Deadlock Avoidance

This approach 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 ( safe or unsafe) is defined by

 the number of available resources
 The number of allocated resources, and
 the maximum resource demands of the processes

70
 Safe State
When a process requests an available resource, system must decide
if immediate allocation leaves the system in a safe state

A state is safe if the system can allocate all resources requested by all
processes ( up to their stated maximums ) without entering a deadlock
state.

More formally, a system is in safe state if there exists a sequence

<P1, P2, …, Pn> of ALL the processes in the systems such that 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
That is:
 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
71
 Cont ...

For example, consider a system with 12 tape drives, allocated as

follows. Is this a safe state? What is the safe sequence?

Maximum Current
Needs Allocation
P0 10 5
P1 4 2
P2 9 2
Yes it is in safe state, since
The sequence <P1, P0, P2> satisfies the safety condition.
What happens to the above table if process P2 requests and is
granted one more tape drive?

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

 Only grant requests that result in safe states

73
 Deadlock Avoidance Algorithms

Single instance of a resource type

 Use a resource-allocation graph

Multiple instances of a resource type

 Use the banker’s algorithm

74
 Resource-Allocation Graph Scheme
Claim edge Pi Rj
 indicate that process Pj may request resource Rj;

 represented by a dashed line

 Claim edge converts to request edge when a process requests a

resource

Request edge converted to an assignment edge when the

resource is allocated to the process

When a resource is released by a process, assignment edge

reconverts to a claim edge

Resources must be claimed a priori in the system

75
 Resource-Allocation Graph

What happens if process P2 requests resource R2 and that request is

granted ?

76
 Unsafe State In Resource-Allocation Graph
The resulting resource-allocation graph would have a cycle in it, and so
the request cannot be granted.

NOTE:- Suppose that process Pi requests a resource Rj , the request

can be granted only iff
 Converting the request edge to an assignment edge does not result in the
formation of a cycle in the resource allocation graph

77
 Banker’s Algorithm

Banker’s algorithm (Dijkstra, 1965)

 Each customer tells banker the max. number of resources needed
 Customer borrows resources from banker
 Customer eventually pays back loan
 Banker only lends resources if the system will be in a safe state
after the loan

Safe state: there is a lending sequence such that all customers

can take out a loan
Unsafe state: there is a possibility of deadlock

78
 Banker’s Algorithm

Works for resources having 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
Safe State
 there is some scheduling order in which every process can run to
completion
 From a safe state, the system can guarantee that all processes will
finish
Unsafe state: no such guarantee
 Not a deadlock state
 Some process may be able to complete
79
 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]

80
 Safety Algorithm

1. Let Work and Finish be vectors of length m and n,

respectively. Initialize:
Work = Available
Finish [i] = false for i = 0, 1, …, n- 1

2. Find an 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
and unsafe otherwise

81
 Resource-Request Algorithm for Process Pi
• Requesti = 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;

Run the safety algorithm then

 If safe  the resources are allocated to Pi
 If unsafe  Pi must wait, and the old resource-allocation state
is restored

82
 Example of 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 010 753 332
P1 200 322
P2 302 902
P3 211 222
P4 002 433
• Is the system in a safe state ?
• Let as run the safety algorithm to check

83
 Example (Cont.)

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

Need Available
ABC ABC
P0 743 332
P1 122
P2 600
P3 011
P4 431

• Find a process whose need is less than available and modify

available as available plus allocation
• If succeeded for all Ps, then it is in safe sate
For this particular case, the system is in a safe state since the
sequence < P1, P3, P4, P2, P0> satisfies safety criteria

84
 Example: P1 Request (1,0,2)
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 2 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
Therefore, the request by p1 can be granted
Questions
 Can request for (3,3,0) by P4 be granted?
 Can request for (0,2,0) by P0 be granted?

85
 Another Example: Is allocation (0 2 0) to P0 Safe?

Process Alloc Max Need Available

A B C A B C A B C A B C
P0 0 1 0 7 5 3 7 4 3 2 3 0
P1 3 0 2 3 2 2 0 2 0
P2 3 0 0 9 0 2 6 0 2
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1

Try to allocate 2 of resource B to P0…

94
94
 Run Safety Test

Process Alloc Max Need Available

A B C A B C A B C A B C
P0 0 3 0 7 5 3 7 2 3 2 3 0
P1 3 0 2 3 2 2 0 2 0 2 1 0
P2 3 0 0 9 0 2 6 0 2
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1

No process can get its max resources and release them

95
 So Unsafe State ⟹ Do Not Enter

• Try to find a process whose need is less than available

• There is no one.

Process Alloc Max Need Available

A B C A B C A B C A B C
P0 0 3 0 7 5 3 7 2 3 2 3 0
P1 3 0 2 3 2 2 0 2 0 2 1 0
P2 3 0 0 9 0 2 6 0 2
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1

Return to safe state; do not allocate resource

96
 P0 Suspended Pending Request
• Restore the system to the state before the request.
Process Alloc Max Need Available
A B C A B C A B C A B C
P0 0 1 0 7 5 3 7 4 3 2 3 0
P1 3 0 2 3 2 2 0 2 0
P2 3 0 0 9 0 2 6 0 2
P3 2 1 1 2 2 2 0 1 1
P4 0 0 2 4 3 3 4 3 1
• When enough resources become available, P0 can
awaken

97
 Results
P0’s request for 2 Bs cannot be granted because that would
prevent any other process from completing if they need
their maximum claim

Just Because It’s Unsafe shouldn't we allocate P0 2Bs?

What are the conditions that doesn't result in deadlock if

P0 is granted 2Bs ?
 P0 could have been allocated 2 Bs and a deadlock might not have
occurred if:
 P1 didn’t use its maximum resources but finished
using the resources it had

98
 Deadlock Detection

Allow system to enter deadlock state

Detection algorithm

Recovery scheme

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

Then, If there is a cycle in the graph, there exists a deadlock

102
Resource-Allocation Graph and Wait-for Graph for
deadlock detection

Resource-Allocation Graph Corresponding wait-for graph

103
 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 [i][j] = k, then process Pi is
requesting k more instances of resource type Rj.

104
 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

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

105
 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 010 000 000
P1 200 202
P2 303 000
P3 211 100
P4 002 002

Sequence <P0, P2, P3, P1, P4> will result in Finish[i] = true for all i

106
 Example (Cont.)

P2 requests an additional instance of type C

Request
ABC
P0 0 0 0
P1 2 0 2
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 P4

107
 Detection-Algorithm Usage
When, and how often, to invoke depends on:
 how often is a deadlock likely to occur
 how many processes will be affected by deadlock when it happens

If deadlocks occur frequently, then the algorithm should be invoked

frequently.

Extreme: invoke the algorithm every time a request is denied

Alternative: invoke the algorithm at less frequent time intervals:
 once per hour
 whenever CPU utilization < 40%
Issue:
 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.

108
 Recovery From Deadlock
 There are two options for breaking a deadlock
1. Process Termination:
a. Kill all deadlocked processes and release resources
b. Kill one deadlocked process at a time and release its resources
 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?
2. Resource Preemption: successively preempt some resources from
processes and give to other processes until the deadlock cycle is broken.
Issues that need to be addressed in this approach:
 Selecting a victim: Which resources and which processes are to be preempted?
 Rollback – return process to some safe state and restart it from that state
 Starvation – same process may always be picked as victim

109
 Deadlock Summary
In general, deadlock detection or avoidance is
expensive
Must evaluate cost of deadlock against detection or
avoidance costs
Deadlock avoidance and recovery may cause
starvation problems
UNIX and Windows use Ostrich Algorithm

110
End of Chapter 6

111