Chapter 5

Deadlock
Synchronization
learning objectives
After completing this chapter, you should be able to describe:

•The basic functionality of the memory allocation methods covered in this chapter:
paged, demand paging, segmented, and segmented/demand paged memory allocation

•The influence that these page allocation methods have had on virtual memory

•The difference between a first-in first-out page replacement policy, a least-recently-

used page replacement policy, and a clock page replacement policy

•The mechanics of paging and how a memory allocation scheme determines which
pages should be swapped out of memory
background
Process
Resource Sharing

Process
M’ment
M’ment Competition for

Problems
limited resources

Problems
Lack of Process Synchronization

Livelock Starvation Deadlock

2 people try to pass Infinite
each other but cannot do postponement of A set of blocked
so because as one steps job processes each holding
to the right, the other a resource and waiting
steps to the left, and to acquire a resource
vice versa, then they held by another process
will continue moving in the set.
but neither will ever
move forward. This is
called livelock. System comes to
standstill and has to
resolved via external
intervention
cases of deadlock
File Jobs request and hold files
File for execution duration
Request
Request

Database Two processes (R1, R2)

Database access and lock database
records (P1. P2):

P1 accesses R1 and locks it

P2 accesses R2 and locks it
P1 requests R2 but locked by P2
P2 requests R1 but locked

• when locking not used

• Causes incorrect final version
of data
• Depends on process execution
order
 Limited number of dedicated
Dedicated devices
Dedicated
Device
Device Two programs (P1, P2)
Allocation Need two tape drives each
Allocation Only two tape drives in system
P1 requests tape drive 1 ,gets it
P2 requests tape drive 2, gets it
P1 requests tape drive 2 ,blocked
P2 requests tape drive 1 ,blocked
Dedicated device made
Spooling sharable
Spooling
Printer: high-speed disk device between printer
and CPU
Disk acts as buffer for users output before
printed
Printer needs all output before printing
Spooling system fills disk space
No job has entire output in spool
partially completed output for all
Results in deadlock

Multiple Several processes request and

Multiple hold dedicated devices
Device
Device
Allocation Three programs (P1, P2, P3)
Allocation Three dedicated devices (tape drive,
printer, plotter)

P1 requests and gets tape drive

P2 requests and gets printer
P3 requests and gets the plotter
P1 requests printer but blocked
P2 requests plotter but blocked
P3 requests tape drive but blocked
Disk Competing processes send
Disk conflicting commands
Sharing
Sharing
Scenario: disk access

Two processes
Each process waiting for I/O request,
One at cylinder 20 and one at cylinder
310.

Deadlock sequence
when R/W arm reaches a track, a
command for other track issued.
Neither I/O request satisfied . Device
puts request on hold while attempting
to fulfill other request

Network No network protocols

Network controlling network message
flow

Seven computers on
network
Each on different nodes
Direction of arrows
Indicates message flow
Deadlock sequence
All available buffer space
fills
conditions for deadlock
Four conditions simultaneously occurring prior to deadlock or livelock

Mutual Allowing only 1 process access to dedicated resource

Mutual
Exclusion
Exclusion When two people meet on the steps, between landings, they can’t pass
because the steps can hold only one person at a time.

Resource Holding resource and not releasing it, Waiting for

Resource other job to retreat All 4 are
Holding
Holding When two people meet on the stairs and each one holds ground and required for
waits for the other to retreat deadlock
occurrence.

No Lack of temporary reallocation of resources Deadlock

No
Preemption each step is dedicated to the climber (or the descender); it is allocated to the holder remains until
Preemption for as long as needed. one condition
removed

Circular Each process involved in impasse.

Circular
Wait there exists a set {P0, P1, …, P0} of waiting processes such that P0 is waiting for a resource
Wait 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.
modelling deadlock
Resource request edge
Resource A set of vertices V and edges E.
Allocation
Allocation V consists of
Graph P = {P1, P2, …, Pn}, (process).
Graph R = {R1, R2, …, Rm}, (resources). e.g, assignment edge Pi
Resource Type with 4 instances
Rj

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.

Cycles, one Cycles , 2

instance per instances per
resource type resource type
examples – 4 scenarios
 Scenario 4

Resources of same type

Allocated individually or grouped in

same process. - Graph clusters
devices into one entity

Allocated individually or grouped in

different process - Graph clusters
devices into one entity
handling deadlocks
Prevent occurrence of one condition -Mutual exclusion, resource holding,
Prevention no preemption, circular wait. Implement during system design stage
Prevention
(before system runs)

Avoid deadlock if it becomes probable. Implement

Avoidance when system is running
Avoidance

Detection Detect deadlock when it occurs

Detection Recover gracefully. Detect when deadlock really happens

Recovery Resume system normalcy quickly and gracefully

Recovery
prevention eliminates one of four
conditions

Complication
every resource cannot be
Complication eliminated from every condition

Mutual Some resources must allocate exclusively

exclusion Bypassed if I/O device uses spooling

Resource Bypassed if jobs request every necessary

holding resource at creation time

No Okay if job state easily saved and restored

Bypassed if operating system allowed to Not accepted to preempt dedicated I/O
preemption deallocate resources from jobs device or files during modification

Circular wait Bypassed if operating system Requires jobs to anticipate

prevents circle formation resource request order
Use hierarchical ordering scheme Difficult to satisfy all users
avoidance use if condition
cannot be removed

System knows ahead of time

• Sequence of requests associated with each active
process
•Dijkstra’s Bankers Algorithm
– Regulates resources allocation to avoid deadlock
• No customer granted loan exceeding bank’s total
capital
• All customers given maximum credit limit
• No customer allowed to borrow over limit
• Sum of all loans will not exceed bank’s total capital
 Given A has 10 instances, B has 5 instances and C has 7 instances

Need = Max - Allocation

Allocation Max Available Need

A B C A B C A B C A B C

P0 0 1 0 7 5 3 3 3 2 P0 7 4 3

P1 2 0 0 3 2 2 P1 1 2 2

P2 3 0 2 9 0 2 P2 6 0 0

P3 2 1 1 2 2 2 P3 0 1 1

P4 0 0 2 4 3 3 P4 4 3 1

system is currently in a safe state with the sequence < P1, P3, P4, P2, P0>

Suppose P1 request - Request1 = (1,0,2).

1. check that Request1 <= Available

(1,0,2) <= (3,3,2) -- true
 Allocation Need Available

A B C A B C A B C

P0 0 1 0 7 4 3

P1 3 0 2 0 2 0 2 1 0 ->

P2 3 0 2 6 0 0
P3 2 1 1 0 1 1

P4 0 0 2 4 3 1

2. We must determine whether this new system state is safe.

To do so, we execute our safety algorithm and find that the sequence <P1, P3, P4, P0, P2>
satisfies the safety requirement. Hence, we can immediately grant the request of process
P1.

Consider , a request for (3,3,0) by P4 cannot be granted, since the resources are not available.
Furthermore, a request for (0,2,0) by P0 cannot be granted, even though the
resources are available, since the resulting state is unsafe.
 Given A has 10 instances, B has 5 instances and C has 7 instances

Initial available is A= 10–7 = 3, B = 5-3 = 3; C =7-5 =2 -> 3 3 2

Need = Max - Allocation
Allocation Max Available Need

A B C A B C A B C A B C

P0 0 1 0 7 5 3 3 0 4 -> 10 5 7 P0 7 4 3

P1 2 0 0 3 2 2 2 1 0 -> 5 3 2 P1 1 2 2

P2 3 0 2 9 0 2 1 4 5 -> 10 4 7 P2 6 0 0

P3 2 1 1 2 2 2 5 2 1 -> 7 4 3 P3 0 1 1

P4 0 0 2 4 3 3 3 1 2 -> 7 4 5 P4 4 3 1

system is currently in a safe state with the sequence < P1, P3, P4, P2, P0>

e r
sw
An
Suppose P1 request - Request1 = (1,0,2).

1. check that Request1 <= Available

(1,0,2) <= (3,3,2) -- true

Initial available = 2 3 0

Allocation 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 0 0 2 -> 7 5 5

P1 3 0 2 3 2 2 0 2 0 2 1 0 -> 5 3 2

P2 3 0 2 9 0 2 6 0 0 1 5 5 -> 10 5 7

P3 2 1 1 2 2 2 0 1 1 5 2 1 -> 7 4 3

P4 0 0 2 4 3 3 4 3 1 3 1 2 -> 7 4 5

Safe sequence = P1, P3, P4, P0, P2

 Operating systems deadlock avoidance assurances
– Never satisfy request if job state moves from safe to unsafe
• Identify job with smallest number of remaining resources
• Number of available resources => number needed for selected job to
complete
• Block request jeopardizing safe state

Problems with the Banker’s Algorithm

– Jobs must state maximum number needed resources
– Requires constant number of total resources for each class
– Number of jobs must remain fixed
– Possible high overhead cost incurred
– Resources not well utilized
• Algorithm assumes worst case
– Scheduling suffers
• Result of poor utilization
• Jobs kept waiting for resource allocation
detection build directed resource
graphs – look for cycles

• Algorithm detecting circularity

– Executed whenever appropriate
• Detection algorithm
– Remove process using current resource and not waiting for one
– Remove process waiting for one resource class
• Not fully allocated
– Go back to step 1
• Repeat steps 1 and 2 until all connecting lines removed
recovery Deadlock untangled once detected
System returns to normal quickly

• All recovery methods have at least one victim

• Recovery methods
– Terminate every job active in system
• Restart jobs from beginning
– Terminate only jobs involved in deadlock
• Ask users to resubmit jobs
– Identify jobs involved in deadlock
• Terminate jobs one at a time

Interrupt jobs with record (snapshot) of progress

Select nondeadlocked job
Preempt its resources
Allocate resources to deadlocked process

Stop new jobs from entering system

Allow nondeadlocked jobs to complete
Releases resources when complete
No victim
Factors to consider when selecting victim:

Select victim with least-negative effect on the

system

Most common
• Job priority under consideration: high-priority jobs usually
untouched

• CPU time used by job: jobs close to completion usually left

alone

• Number of other jobs affected if job selected as victim

• Jobs modifying data: usually not selected for termination (a

database issue)
 starvation
• Job execution prevented
– Waiting for resources that never become available
– Results from conservative resource allocation

• Example
– “The dining philosophers” by Dijkstra

• Starvation avoidance
– Implement algorithm tracking how long each job waiting for
resources (aging)
– Block new jobs until starving jobs satisfied
 the dining philosophers by Dijkstra

Each philosopher must alternately think and eat. However, a

philosopher can only eat spaghetti when they have both left
and right forks. Each fork can be held by only one
philosopher and so a philosopher can use the fork only if it is
not being used by another philosopher.

After an individual philosopher finishes eating, they need to

put down both forks so that the forks become available to
others. A philosopher can take the fork on their right or the
one on their left as they become available, but cannot start
eating before getting both forks.

The problem is how to design a discipline of behavior (a concurrent algorithm) such that no
philosopher will starve; i.e., each can forever continue to alternate between eating and
thinking, assuming that no philosopher can know when others may want to eat or think.
consider a solution…

•think until the left fork is available; when it is, pick it

up;
•think until the right fork is available; when it is, pick it
up;
•when both forks are held, eat for a fixed amount of
time;
•then, put the right fork down;
•then, put the left fork down;
•repeat from the beginning

Suggest…
This solution to the problem is the one
originally proposed by Dijkstra.

It assigns a partial order to the resources (the forks, in this case), and establishes the
convention that all resources will be requested in order,
and that no two resources unrelated by order will ever be used by a single unit of work
at the same time.

Here, the resources (forks) will be numbered 1 through 5 and each unit of work
(philosopher) will always pick up the lower-numbered fork first, and then the higher-
numbered fork, from among the two forks they plan to use.

The order in which each philosopher puts down the forks does not matter. In this case,
if four of the five philosophers simultaneously pick up their lower-numbered fork, only
the highest-numbered fork will remain on the table, so the fifth philosopher will not be
able to pick up any fork. Moreover, only one philosopher will have access to that
highest-numbered fork, so they will be able to eat using two forks.