Chapter 5
Process Management
2015 - Semester 2
Objectives



What is a deadlock?
Seven cases of deadlocks
Conditions of deadlocks
–
–
–
–

Mutual exclusion
Recourse holding
No preemption
Circular wait
Modelling deadlocks
 Resource allocation graphs

Strategies for handling deadlocks







Prevention
Avoidance
Detection
Recovery
Banker’s algorithm
Safe and unsafe states
Starvation
Deadlocks
 Resource sharing
– Memory management and processor sharing
 Many programs competing for limited resources
 Lack of process synchronization consequences
– Deadlock:
• A problem occurring when the resources needed by some jobs to
finish execution are held by other jobs, which, in turn, are
waiting for other resources to become available.
• Two or more jobs placed in HOLD state
• Jobs waiting for unavailable vital resource
• System comes to standstill
• Resolved via external intervention
– Starvation
• Infinite postponement of job
Deadlocks (cont.)
 Affects entire system
– Affects more than one job
• Not just a few programs
– All system resources become unavailable
 More common in interactive systems
 Real-time systems
– Deadlocks quickly become critical situations
 No simple and immediate solution
Deadlocks (cont.)
EXAMPLES:
"It takes money to make money".
“You can't get a job without experience; you can't get experience without a
job”.
BACKGROUND:
The cause of deadlocks: Each process needing what another process has.
This results from sharing resources such as memory, devices, links.
Under normal operation, a resource allocations proceed like this:
1.
2.
3.
Request a resource.
Use the resource.
Release the resource.
Deadlocks (cont.)
Seven Cases of Deadlocks
 Non-sharable /non-preemptable resources
– Allocated to jobs requiring same type of resources
 Resource types locked by competing jobs
– File requests
– Databases
– Dedicated device allocation
– Multiple device allocation
– Spooling
– Disk sharing
Homework:
– Network
Read about these cases in the textbook.
Conditions for Deadlocks
 Four conditions simultaneously occurring prior to
deadlock:
–
–
–
–
Mutual exclusion
Resource holding
No preemption
Circular wait
 All needed by operating system
– Must recognize simultaneous occurrence of four
conditions
 Resolving deadlock
– Removal of one condition
Conditions for Deadlocks (cont.)
Mutual Exclusion
 Allowing only one process access to dedicated
resource.
 If another process requests that resource, the
requesting process must be delayed until the
resource has been released.
Resource holding
 a process that holding at least one resource (and not
releasing it) and is waiting to acquire additional
resources held by other processes.
Conditions for Deadlocks (cont.)
No preemption
 Lack of temporary reallocation of resources
 A resource can be released only voluntarily by the process
holding it, after that process has completed its task.
Circular wait
 Must be in a circular chain of 2 or more processes.
 Each process is waiting for a resource held by the next
member in the chain or circle
• Waiting voluntarily resource release by another so at least one
can continue
 All four required for deadlock occurrence
 Deadlock remains until one condition is removed
Modeling Deadlocks
 Directed Graphs
Process
Resource
A
R
Request a Resource
Hold a Resource
Deadlock
R
A
A
– When there is a circle
R
A
R
S
B
Modeling Deadlocks (cont.)
(figure 5.7)
In (a), Resource 1 is
being held by Process 1
and Resource 2 is held by
Process 2 in a system that
is not deadlocked. In (b),
Process 1 requests
Resource 2 but doesn’t
release Resource 1, and
Process 2 does the
same— creating a
deadlock. (If one process
released its resource, the
deadlock would be
resolved.)
Basic facts:
• No circles => no deadlocks © Cengage Learning 2014
• If graph contains a circle:
• If only one instance per type, then
deadlock.
• If several instances per resource
type, then possibility of deadlock.
Modeling Deadlocks (cont.)
Deadlocks
Resource allocation graph
Resource allocation graph
with a deadlock
Resource allocation graph
with a cycle but no deadlock
Modelling Deadlocks
 Three graph scenarios to help detect deadlocks
– System has three processes (P1, P2, P3)
– System has three resources (R1, R2, R3)
(table 5.1)
Scenario 1. These
events are shown in
the directed graph in
Figure 5.8.
© Cengage Learning 2014
 No deadlock
– Resources released before next process request
(figure 5.8)
First scenario. The system will stay
free of deadlocks if each resource
is released before it is requested by
the next process.
© Cengage Learning 2014
Modelling Deadlocks
 Three graph scenarios to help detect deadlocks
– System has three processes (P1, P2, P3)
– System has three resources (R1, R2, R3)
(table 5.2)
Scenario 2. This
sequence of events is
shown in the two
directed graphs shown
in Figure 5.9.
© Cengage Learning 2014
 Deadlock
– Processes waiting for resource held by another
(figure 5.9)
Second scenario. The system
(a) becomes deadlocked (b)
when P3 requests R1. Notice
the circular wait.
© Cengage Learning 2014
Modelling Deadlocks
 Three graph scenarios to help detect deadlocks
– System has three processes (P1, P2, P3)
– System has three resources (R1, R2, R3)
No deadlock
(table 5.3)
Scenario 3. This
sequence of events
is shown in the
directed graph in
Figure 5.10.
© Cengage Learning 2014
– Resources
released before
deadlock
(figure 5.10)
The third scenario.
After event 4, the
directed graph looks
like (a) and P2 is
blocked because P1 is
holding on to R1.
However, event 5
breaks the deadlock and
the graph soon looks
like (b). Again there is a
blocked process, P3,
which must wait for the
release of R2 in event 7
when the graph looks
like (c).
© Cengage Learning 2014
Strategies for Handling Deadlocks
Ignore Deadlocks
Ensure deadlock never occurs using either:
Prevention Prevent any one of the 4 conditions (mutual
exclusion, resource holding, no preemption or
circular wait) from happening.
Avoidance Allow all deadlock conditions, but calculate cycles
about to happen and stop dangerous operations..
Allow deadlock to happen. This requires using both:
Detection Know a deadlock has occurred.
Recovery
Resume system normalcy quickly and gracefully and
regain the resources
Strategies for Handling Deadlocks (cont.)

Prevention eliminates one of four conditions
– Complication: same condition cannot be eliminated from every resource.
– Mutual exclusion
• Some resources must allocate exclusively
• Bypassed if I/O device uses spooling
• Shared entities (read only files) don't need mutual exclusion (and aren’t susceptible
to deadlock).
• Prevention not always possible since some devices are intrinsically non-sharable
– Resource holding
• One approach requires that each process be allocated all of its resources before it
begins executing
• Alternatively, only allow a process to request resources when it currently has none
• Bypassed if all jobs request every necessary resource are known at creation time
• A particular resource can only be requested when no others are being held. A
sequence of resources is always collected beginning with the same one.
• Multiprogramming degree significantly decreased
• Idle peripheral devices
• Utilization is low, starvation possible.
Strategies for Handling Deadlocks (cont.)
 Prevention (cont.)
– No preemption
• Release any resource already being held if the process can't get an additional
resource
• Bypassed if operating system allowed to deallocate resources from jobs
• Okay if job state easily saved and restored
• Not accepted to preempt dedicated I/O device or files during modification
• Allow preemption - if a needed resource is held by another process, which is also
waiting on some resource, steal it. Otherwise wait.
– Circular wait
•
•
•
•
Bypassed if operating system prevents circle formation
Use hierarchical ordering scheme
Requires jobs to anticipate resource request order
Difficult to satisfy all users
EACH of these prevention techniques may cause a decrease in utilization
and/or resources. For this reason, prevention isn't necessarily the best
technique. Prevention is generally the easiest to implement.
Strategies for Handling Deadlocks (cont.)
Avoidance
If we have prior knowledge of how resources will be requested, it's possible
to determine if we are entering an "unsafe" state.
Possible states are:
Deadlock
No forward progress can be made.
Unsafe state A state that may allow deadlock.
Safe state
A state is safe if a sequence of processes exist such that
there are enough resources for the first to finish, and as each
finishes and releases its resources there are enough for the
next to finish.
The rule is simple: If a request allocation would cause an unsafe state, do not
honor that request.
Strategies for Handling Deadlocks (cont.)
 Avoidance: If the OS cannot remove one of the
deadlock condition, it can avoid one if:
– System knows ahead of time the 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
Handling Deadlocks (cont.)
Banker’s algorithm
Handling Deadlocks (cont.)
Banker’s algorithm
Safe state
1 resource with 12 units of that resource available.
Current State: Free = (12 – (5 + 2 + 2)) = 3
Unsafe state
What if P2 requests 1 more and is allocated 1 more?
New state:
Handling Deadlocks (cont.)
 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
Handling Deadlocks (cont.)
 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
Handling Deadlocks (cont.)
 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
Look for the examples in the textbook
Handling Deadlocks (cont.)
 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
Handling Deadlocks (cont.)
 Recovery methods (cont.)
– Interrupt jobs with record (snapshot) of progress
– Select non-deadlocked job
• Preempt its resources
• Allocate resources to deadlocked process
– Stop new jobs from entering system
• Allow non-deadlocked jobs to complete
• Releases resources when complete
• No victim
Handling Deadlocks (cont.)
 Factors to consider:
– 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
Starvation
Homework
Read chapter 5 in the textbook!!
End