Transcript cs320ch7powerpoint

Chapter 7, Deadlocks
1
7.1 System Model
• In order to talk about deadlocks in a system,
it’s helpful to have a model of the system
• A system consists of a set of resources
• The resources can be grouped into types
• Processes compete to have (unique) access to
instances of the types
2
• Examples of resource types:
– Memory locations
– CPU cycles
– Files
– Object locks
– I/O devices (printers, drives, etc.)
3
• When classifying by type, each item has to be
interchangeable
• Otherwise, it’s necessary to classify into
(distinct) subtypes
4
• Each process can request (and hold) as many
resources as needed to complete its work
• Each process may request one or more
instances of one or more types of resource
5
• It makes no sense for a process to request
more instances of resources than exist
• Such a request can only be denied and such a
process cannot do whatever it supposedly was
intended to do
6
• Request/Use sequence
– Request the resource
– This request will either be granted or not
– If granted, use the resource
– After use, release the resource
• Note that “use” will involve a certain period of
time when the process holds the resource
7
• Request and release are forms of system calls
• As usual, you may make explicit calls, or the
compiler may generate them from your source
code
• Examples:
– You can open and close files
– You can request and release devices
– You can allocate and de-allocate (free) memory
locations
8
• The O/S manages access to shared system
resources
• User level resource sharing may also be
implemented in synchronized application code
• The general plan of action for synchronization
described in the previous chapter applies to
system level resource management
9
• Aspects of system resource management:
• The O/S keeps a list of resources and records
which have been allocated to which process
• For processes that couldn’t acquire a resource,
there is a separate waiting list for each
resource
10
• In other words, the system records process
status both implicitly and explicitly
• If a process’s PCB is in a waiting list for a given
resource, its status relative to that resource is
clear
• If some resource relevant piece of information
is recorded in a process’s PCB, its status
relative to that resource is clear
11
Deadlock
• Deadlock is a condition involving a set of
processes and a set of resources
• It is the processes that are referred to as being
deadlocked
• Resources are not referred to as being
deadlocked
• It is contention for the resources by the
processes that causes the processes to
become deadlocked
12
Definition of deadlock
• Verbal definition of deadlock:
• Each process in the set of deadlocked
processes is waiting for an event which can
only be caused by another process in that set
• The event being waited for is the release of a
resource
• More specifically, the event being waited for is
the release of a lock on a resource
13
• There is a slight distinction between holding
resources and holding locks on the resources
• Access to the resource is managed through
access to or possession of the lock
• Cars and car titles provide an analogy
• If you hold the title, then you own the car
• The title, or lock, is a stand-in for the car, or
resource, for the purpose of ownership/access
protocols
14
• Hypothetically, access to resources could be
granted directly, without some lock concept
between the process and the resource
• In that case, deadlock could literally occur on
the resources
15
• In practice, access to a resource is managed
through a semaphore, a lock, or some other
control mechanism
• As a consequence, in an implementation of an
access protocol, deadlock typically occurs on
the stand-in, the lock or other mechanism, not
on the resource itself
16
Characteristics of deadlock
• Under correct synchronization, deadlock
should not be possible on one resource
• Either one process has it or another does
• The process that doesn’t is simply waiting for
it to be released by the other process
• If there are no other resources under
contention, then no other conditions can
apply to the release and acquisition of the
resource
17
• Deadlock can occur with as few as two
contending processes and two shared
resources
• Deadlocks can occur on instances of one kind
of resource type or instances of various kinds
of resource type
• The number of processes and resources
involved in a deadlock can be arbitrarily large
18
• The place you are most likely to concretely
encounter deadlock is in Java thread
programming
• Mutual exclusion meets the requirements for
a process action that has the effect of a lock.
• Mutual exclusion means that one thread locks
another out of a critical section
• Under the covers Java synchronization is in
fact managed by an object’s inherited lock
19
• If an application has >1 thread, there is the
potential for sharing resources among the
threads
• A critical section itself can qualify as the shared
resource
• If an application has shared resources, then
synchronization is necessary so that the code is
thread safe
• Synchronized code with >1 thread and >1
resource has the potential for deadlock
20
7.2 Deadlock Characterization
• Necessary conditions for deadlock:
• 1. Mutual exclusion (locking): There are
common resources that can’t be shared
without concurrency control
• 2. Hold and wait: Once processes have
acquired resources (locks) they’re allowed to
hold them while waiting for others
21
• 3. No pre-emption: Resources can’t be preempted (swiped from other processes).
– A process can only release its resources voluntarily
• 4. Circular wait: This condition is actually
redundant.
– The previous three conditions imply this one,
which is essentially a complete statement of what
deadlock is
22
A summary of deadlock
• If processes can’t acquire resources, they wait.
• If process x is waiting for a resource held by
process y, and y is waiting for a resource held
by x, this is circular wait
23
Resource allocation graphs
• It turns out that it’s relatively easy to
understand deadlocks by looking at diagrams
of them
• Processes, Pi, can be represented as circles
(labeled)
• Groups of equivalent resources, Ri, can be
represented as boxes
• If there is more than one instance of a type,
let it be represented by a dot in the box
24
• Let a request by a process for a resource be
represented by an arrow from the process to
the resource
• Let the granting of requests, if successful, be
immediate.
• A request arrow will only be shown in cases
where the request could not be granted
• Stated more precisely, the arrow represents a
request that has not yet been granted
25
• Let the granting of requests also be atomic, as
well as immediate
• If a request is made, it is either granted or not
granted
• The granting can’t be interrupted
• A request can’t hang in an indeterminate state
26
• Suppose that a resource request is granted
• The assignment of a resource to a process is
represented by an arrow from the resource to
the process
• If there is more than one instance of the
resource, the arrow should go from the
specific dot representing that instance
27
• A graph that uses the foregoing conventions is
known as a resource allocation graph.
• Illustrations follow
28
Pi requesting and being granted an
instance of Rj
29
Graphical definition of deadlock
• A graph is a structure consisting of nodes and
arcs that connect them
• A graph may be directed or undirected
• In an undirected graph, the arcs do not have a
direction
• A cycle in an undirected graph is simply a
connected path through the graph
30
• A resource allocation graph is a directed graph
• Its nodes are connected with arrows, which
have a direction
• A cycle in a directed graph is a connected path
where all the arrows point in the same
direction
31
• If there is only one instance of each kind of
resource type, the following statement holds:
• A cycle in the resource allocation graph
implies a deadlock
• A diagram of the simple, classical case follows
32
33
Non-graphical notation
• Resource allocation graphs can be represented
using set notation
• You can probably expect at least one test
question where the set-up is given using set
notation and you have to draw the graph
• Or possibly, a scenario would be given using set
notation and you would be asked if there was
deadlock
• To answer the question, you would most likely
draw the graph for yourself
34
• Using the book’s conventions, the processes
are represented as P, the resources as R, and
the arcs, or edges, connecting them, as E
• The previously given graph could be
summarized in this way:
• P = {P1, P2}
• R = {R1, R2}
• E = {R1 → P1, P1 → R2, R2 → P2, P2 → R1}
35
Waiting, but without deadlock
• The book’s next example includes multiple
resource types and multiple processes
• It also includes multiple dots per box,
representing multiple instances of a resource
• With more than one instance of a resource
type, even if there is a cycle in the graph,
there may or may not be deadlock
36
• However, this principle holds, whether there is
more than one instance of a resource type or
not:
• If there is no cycle in the graph, there is no
deadlock
• In other words, if you want to talk like a
mathematician, a cycle is a necessary, but not
sufficient condition for a deadlock in a general
resource allocation graph
37
• A resource allocation graph illustrating the
example is given on the next overhead
• The graph does not include a cycle
• If you analyzed it, you might determine that
certain processes may have to wait for other
processes to finish with resources
• But deadlock will not occur
38
39
• The next example illustrates a case with
deadlock
40
41
• The next example illustrates a case where
there is a cycle in the resource allocation
graph, but there is no deadlock
• A verbal description of the situation is given
next—but it can essentially be skipped
• The lack of a deadlock should be apparent
from the diagram which follows
42
• There is no deadlock because, of the multiple
instances of resource R1 which are held, one is
held by P2, which is not in the cycle.
• Similarly, one instance of R2 is held by P4, which
is not in the cycle
• If P2 gives up R1, R1 will immediately be assigned
to P1, and the cycle in the graph will disappear.
• Likewise, if P4 gives up R2, R2 will immediately be
assigned to P3, and the cycle in the graph will
disappear
43
44
7.3 Methods for Handling Deadlocks
• There are three major approaches to deadlock
handling
• 1. Implement synchronization protocols so
that deadlock can’t happen
• 2. Implement synchronization protocols so
that deadlock can be fixed if it does happen
• 3. Do not implement any particular protocols
to handle deadlock; ignore it
45
• 1. Use techniques so that a system never
enters the deadlocked state
– A. Deadlock prevention
– B. Deadlock avoidance
• 2. Allow systems to deadlock, but support:
– A. Deadlock detection
– B. Deadlock recovery
46
• 3. Ignore the problem—in effect, implement
processing without regard to deadlocks
– System problems may occur
– These might be high waiting times/slow
performance/no progress
– These may be the result of deadlocked processes
– If they do occur, deal with them on a special case
basis
47
• 3. Continued—justification:
– There are many reasons why systems go down
– Administrative tools have to exist to re-start
processing in any case.
– Deadlock may only occur rarely
– If it does, it can be handled as a special case
requiring the use of the system re-start tools
– In a simple case, rebooting may be the system restart tool that is available
48
• Consider these observations:
– How many times a year, on average, do you press
CTRL+ALT+DEL on a Windows based system?
– Luckily, it is much less frequent now than it was before
– Hypothesize that in a given environment, the need to
do this due to deadlock would occur once a year
– Under these circumstances, would it be worthwhile to
implement a separate deadlock handling mechanism?
49
• This discussion doesn’t just apply to Windows
based systems.
• Simple implementations of Unix do not have
any special deadlock handling mechanism
• It may not be elegant, but it’s easy to reboot,
and suitable for systems without high
performance expectations (like round-theclock availability)
50
Deadlock handling in Java
• The book’s explanation may leave something
to be desired
• The book’s example program is so confusing
that I will not pursue it
• This section will mention deadlock handling in
Java without going into concrete detail
• It will then go on to a general discussion of the
three approaches to dealing with deadlock
51
• The situation in Java can be summarized in
this way:
• Java doesn’t contain any specific deadlock
handling mechanisms
• If threaded code may be prone to
deadlocking, then it’s up to the application
programmer to devise the deadlock handling
52
• It is worth keeping in mind that the Java API
contains these methods, which apply to
threads, and have been deprecated:
• suspend(), resume(), and stop()
• Part of the reason for deprecating them is that
they have characteristics which impinge on
deadlock
53
• The suspend() method causes the currently
running thread to be suspended
• Even though it’s suspended, it will continue to
hold all the locks it has acquired
• Compare this to a call to wait(), where the
thread is placed outside of the monitor
• It can’t hold a lock on the critical section if it’s
outside the monitor
54
• The resume() method causes a thread to start
again, but this call to resume can only be
made in some other, running thread
• If the suspended thread holds locks required
by the other thread which contains the call to
resume the suspended thread, deadlock will
result
55
• The stop() method isn’t directly deadlock
prone
• As pointed out some time ago, it is simply
prone to lead to inconsistent state
56
• Consider this typical sequence of events:
– Acquire a lock
– Access a shared data structure
– Release the lock
• When stop() is called, all locks held by the
thread are immediately released
57
• In confused code, stop() could be called at a
point where a shared resource has undergone
incomplete modification
• In other words, the call to stop() will cause
locks to be released before the point where
they should be
• Compare this with a call to interrupt()
• If a thread is interrupted, it is allowed to do
housekeeping before it finally quits
58
• It may seem odd that a programmer would call stop()
somewhere during the modification of a shared
resource, but
• Hamlet:
...
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
Hamlet Act 1, scene 5, 159–167
59
• In short
• In Java, it’s the programmer’s problem to
write code that isn’t deadlock prone
• There are definitely things in the Java API to
avoid if you are worried about deadlock
• In particular, keep in mind that your code will
be problem-prone if you use calls to the
methods suspend(), resume(), or stop()
60
• The book’s example program is not the ideal
vehicle for seeing how to solve this as a
programmer
• I don’t have the time to dream up a better
example
• Therefore, I won’t claim to have told you how
to do this correctly
• You’ll have to settle for the warning about
how not to do it incorrectly
61
7.4 Deadlock Prevention
• The first of the three major approaches to
handling deadlock was to implement
synchronization protocols so that deadlock
can’t happen
• The first of the two sub-approaches under this
heading was deadlock prevention
62
•
•
•
•
•
Recall the preconditions for deadlock:
1. Mutual exclusion (locking)
2. Hold and wait
3. No pre-emption
4. Circular wait (redundant)
63
• The basic idea behind deadlock prevention is
to implement a protocol (write code) where at
least one of the preconditions can’t hold or is
disallowed
• That means that in theory there can be a
deadlock prevention implementation based
on each of the different preconditions
64
1. Disallowing mutual exclusion
• This is not an option
• It’s true that without mutual exclusion,
deadlock is impossible, but this consists solely
of wishing the problem away
• The whole point of the last chapter was the
fact that in some cases mutual exclusion is
necessary, and it is therefore necessary to be
able to manage the deadlock that comes
along with it
65
• In support of the need for mutual exclusion,
the book finally gives a rock-bottom simple
example of a shared resource managed by the
O/S where mutual exclusion is necessary:
• Having given the printer to one process, it is
out of the question to interrupt it and hand
the resource over to another process in the
middle of a print job
66
2. Disallowing hold and wait
• This is doable
• There are two basic approaches:
– A. Request (and acquire) all needed resources
before proceeding to execute—in other words,
acquire up front
– B. Only request needed resource(s) at a point
when no others are held—in other words, acquire
as you go, but only at “safe” points
67
• Both option A and option B are kinds of block
acquisition.
• B is a finer grained version of it than A—a
single process may request and release >1
block of resources over time
• Note that “wait” in the phrase “hold and wait”
means wait for other needed resources to
become available
68
Problems with disallowing hold and
wait:
• Low resource utilization—because processes
have to grab and hold everything they need,
even when they’re not using it
• If B is impractical, A is forced, but A is the
more drastic choice where more unused
resources are held for longer times
• Starvation is possible if a process needs a large
set of resources and has to be able to acquire
them all at the same time
69
• In general, the underlying goal of a multitasking system is concurrency.
• Disallowing hold and wait reduces
concurrency
• Processes that aren’t deadlocked may not be
able to run because they require a resource
another process is holding but not using
70
• Note that disallowing hold and wait is not very
practical in Java.
• Java doesn’t have syntax for simultaneous block
acquisition of a group of resources
• In user code, it might be possible to group
acquisition requests for multiple resources
together in one critical section
• However, trying to implement deadlock
prevention in this way in application code would
probably be problematic
71
3. Disallowing no pre-emption
• Implement a protocol which allows one
process to take locks/resources away from
other processes as needed
• There are two approaches, given below
72
• 1. Self-pre-emption: The requesting process
gives up resources
– If process P holds resources and requests
something that’s unavailable because it’s held (by
process Q, for example), process P releases the
resources it has already acquired
– Process P will have to start over from scratch
73
• 2. External pre-emption: The requesting process
takes resources
– If process P requests something that’s unavailable
because it’s held by process Q, and process Q in turn
is also waiting for resources, then process Q is
required to release its resources and process P takes
what it needs
– In this case, process Q was pre-empted and will have
to start over from scratch
– If process Q is active, not waiting, when P makes its
request, then pre-emption will not occur and P will
have to wait
74
• Note that pre-emption based deadlock
protocols are related in nature to pre-emptive
scheduling and context switching
• The CPU itself is a resource shared among
processes
• Registers and other system components are
examples of specific parts of this resource
• One process can interrupt, or pre-empt
another, and take the shared resource
75
• In any pre-emption based system, the critical
point is that whatever is pre-empted has to be
left in a consistent state
• Context switching can be made to work
because the state of the pre-empted process
can be saved and restored
• Pre-emption to deal with deadlock also has to
concern itself with maintaining consistent
state
76
• In the verbal description of the deadlock
algorithms, the statement was made that preempted processes would have to start from
scratch
• That didn’t mean that users would have to
resubmit them
• It meant that the system would keep a record of
the resources they had requested, and when they
were scheduled again, the first order of business
would be re-acquiring those resources
77
• Keep in mind that in some cases, pre-emption
is simply not a practical option.
• A simple, concrete example would be
acquisition of a printer.
• If a process has already acquired a printer, it
should not give it up until it’s finished with it
• Chaos results if the printed output consists of
interleaved print jobs
78
• The reality is that there is more to preemption than meets the eye.
• The critical question when pre-empting is
whether or not the pre-empted process
already accomplished some work
• This is connected with the concept of
atomicity
79
• The internal logic of a transaction may require
that various sub-parts of it be executed
together, all or nothing
• Translated into the terminology of locks, this
would mean that the transaction would have
to hold the locks for the sub-parts
simultaneously, not sequentially
80
• If deadlock prevention involved pre-emption,
it would be necessary to make sure that the
pre-emption didn’t interrupt the atomic
transaction
• In other words, if there are interdependent
locked resources, if the transaction has
accessed one resource, it can’t give up its
locks until it’s accessed the other resource
81
4. Disallowing circular wait
• Although “circular wait” is in a sense
redundant, it encapsulates the idea behind
deadlock and it suggests a solution
– 1. Number the resource types
– 2. Only let processes acquire items of types in
increasing resource type order
– 3. A process has to request all items of a given
type at the same time
82
• Why does this work?
• Examine the classic case of deadlock, and
observe how it doesn’t meet the requirements
listed above:
83
84
• The order of actions for P1:
– Acquire R1
– Request R2
• The order of actions for P2:
– Acquire R2
– Request R1
• P2 did not acquire/try to acquire resources in
ascending order by type
85
• If all processes acquire in ascending order,
waiting may result, but deadlock can’t result
• This is the verbal explanation
– Suppose process 1 holds resources a, b, c, and
requests resource x
– Suppose process 2 holds x
– Process 1 will have to wait for process 2
86
– However, if process 2 already holds x, because it
acquires in ascending order, it cannot be waiting
for resources a, b, or c
– It may already have acquired copies of those
resources that it needs, or it may not need them
at all, but it will not be going back to try and get
them
– Therefore, it is not possible for process 1 and
process 2 to be deadlocked
87
• A variation on the previous idea
• Suppose a process reaches an execution point
where it becomes clear that a resource with a
smaller number is now needed
• The process will have to release all resources
numbered higher than that one and acquire
them again—in ascending order
• This is obviously costly
88
7.5 Deadlock avoidance
• The first of the three major approaches to
handling deadlock was to implement
synchronization protocols so that deadlock can’t
happen
• The first of the two sub-approaches under this
heading, deadlock prevention, was just covered
• It worked by disallowing one of the preconditions
for deadlock
• Deadlock prevention is essentially a technique
that reduces concurrency
89
• The second of the two sub-approaches under
this heading of making sure that deadlock
doesn’t happen is deadlock avoidance
• Deadlock avoidance is based on having more
information about resource requests by
processes
• With sufficient knowledge, requests may be
ordered/granted in a way that will not lead to
deadlock
90
• Deadlock avoidance potentially solves the
deadlock problem while still allowing high
levels of concurrency
• Under simple deadlock prevention, processes
have to acquire all of their resources up front.
• Under simple deadlock avoidance, processes
have to declare all of their resource needs up
front
• The protocol then works from there
91
Deadlock avoidance and safe states
• In order to formally define a deadlock
avoidance algorithm, it’s necessary to define a
safe state
• Informally, a safe state is a situation where
granting a resource to a process will not cause
deadlock
• Conversely, an unsafe state is one where
granting a resource to a process would cause a
deadlock
92
• It’s worthwhile to keep in mind that we’re
worried about safe states under the condition
that some resources are already held by some
processes
• If no processes hold any resources, granting a
resource could not lead to an unsafe state
93
• Informally, deadlock prevention algorithms
prevent a system from entering a deadlocked
state
• Deadlock avoidance is one step removed from
that
• Under deadlock avoidance, a system is not
allowed to enter an unsafe state
94
• Under deadlock avoidance a system is not
allowed to enter a state where it would be
dangerous to grant a resource because
granting it would cause deadlock
• Under a deadlock avoidance algorithm the
system moves only from one safe state to
another, always avoiding the possibility of
deadlock
95
Definitions needed for deadlock to
discuss deadlock avoidance in detail
• In order to formally define a safe state, it’s
necessary to define a safe sequence
• A sequence refers to a numbered set of
processes, which can be shown using this
notation:
• <P1, P2, …, Pn>
• A safe sequence has this property:
• For all Pj, Pj’s resource requests can be satisfied
by free resources or resources held by Pi, where i
< j.
96
• Safe state:
• Formal definition: A system is in a safe state if
there exists a safe sequence
• Informal definition: A system is in a safe state
if it can allocate resources to processes in
some order without deadlock
• Practical consequence: The goal, then, is to
find a safe sequence, and allocate resources in
sequence order
97
• You don’t necessarily identify the safe
sequence all at once
• A deadlock avoidance protocol can be
regarded as an iterative process
• A resource is granted to a process under the
condition that the resulting state is safe
• Then the next resource can be granted to a
process under the same condition
• The iteration continues
98
• As long as the safe state condition can be met
each time a resource is granted, eventually all
requests will be met
• In the course of granting resources, the system
will have moved from one safe state to another
• There may be many different possible paths
through the iteration, which would go through
different safe states
• What’s important is that at least one series of
safe states can be found
99
• Notice how deadlock avoidance is related to
the idea of circular wait
• Under the definition given for a safe sequence
of processes, a process Pj can be waiting, but
only on Pi where i < j
• Pj can’t be waiting on some Pk where k > j
100
• More specifically, Pi can’t be waiting on Pj
• Waiting, or dependency, only goes in
sequential order, ascending by subscript
• As a consequence, there can be no circular
waiting in a safe sequence
101
• If there is no circular waiting, then it would be
possible to grant a resource to one of the
processes without causing deadlock
• Deadlock avoidance says, additionally, that
you can only grant the resource if the result is
a state which is also safe
• If so, then the granting of resources can
continue indefinitely
102
• Five observations can be made based on these
definitions:
• 1. Certainly, a safe state is not deadlocked
• 2. Also, granting a resource in a safe state
cannot result immediately in deadlock
• 3. Incidentally, a deadlocked state is not safe
103
• 4. There are unsafe states that are not yet
deadlocked, but the granting of a resource
from such a state would result in deadlock
• 5. When in a safe state, the goal is to avoid
granting a resource in such a way that the
system goes into an unsafe state
104
• This is a scenario that illustrates an unsafe
state:
• Pi has requested/is waiting for Pj
• This is unsafe, because it is a “forward” wait
• Pj hasn’t yet made a request on Pi
• If it did, it would be a legal request
• But in the presence of the pre-existing
forward wait, it would cause deadlock
105
• Under deadlock prevention, you avoid going
into a deadlocked state
• Under deadlock avoidance, you want to avoid
going into an unsafe state
106
• Allocations of currently free resources can
cause a system to move from a safe to an
unsafe state
• Because processes pre-declare their needs, an
unsafe state (leading to possible deadlock) can
be foreseen based on other requests and
allocations that will be made
107
• There are several algorithms for deadlock
avoidance
• They all prevent a system from entering an
unsafe state
• The algorithms are based on pre-declaration
of needs, but not immediate acquisition of all
resources up front
108
• Like deadlock prevention algorithms, deadlock
avoidance algorithms tend to have the effect
of reducing concurrency
• Their level of concurrency reduction is low
because not all resource acquisitions have to
happen up front
109
Resource allocation graph algorithm
for deadlock avoidance
• Let the previous explanation of the resource
allocation graph stand:
– Let a request by a process for a resource be
represented by an arrow from the process to the
resource
– When a request is made, it may be granted or not,
but if it is, the granting is atomic
– Let the granting, or assignment, of a resource to a
process be represented by an arrow from the
resource to the process
110
• For deadlock avoidance, let a new kind of
edge, a claim edge, be added to the notation
– A claim edge goes in the same direction as a
request, but it’s dashed
– A claim edge represents a future request that will
be made by a process
111
• The resource allocation graph algorithm says:
– Requests for resources can only be granted if they
don’t lead to cycles in the graph
– When identifying cycles, the dashed claim edges
are included
– The point is that a cycle in the graph now indicates
an unsafe state
112
• What follows is a sequence of diagrams showing
two processes progressing towards an unsafe
state
• The initial diagram only shows claim edges.
• These are the pre-declared requests of the
processes
• The claim edges are converted into request and
grant edges as processing progresses
• The last request can’t be granted because it
would lead to an unsafe state
113
• 1. All future requests are predeclared
• 2.A. P1 requests R1
• 2.B. P1 is granted R1
114
• 3. P2 requests R1. P2 is not granted R1
• 4.A. P2 requests R2
• 4.B. P2 is granted R2.
115
• The last state contains a cycle.
• It is unsafe.
• From that state, if R1 then requested R2
before anything was released, deadlock would
result.
• You can’t enter a state from which you could
enter deadlock.
116
• State 3 is the last safe state.
• Therefore, under deadlock avoidance P2’s
request for R2 can’t be granted
• The system can’t go from state 4.A to 4.B,
even though 4.B is not deadlocked.
• Remember, 4.A and 4.B are atomic
• The request would be made and rejected, and
the system would remain in state 3
117
Aspects of the resource allocation graph
algorithm for deadlock avoidance
• This algorithm is based on pre-declaring all
claims
• The pre-declaration requirement can be
relaxed by accepting new claims if all of a
process’s edges are still only claims
118
• Implementing a deadlock avoidance algorithm
would require the implementation of a cycle
detection algorithm in the resource allocation
graph.
• The authors say this is within reason because
such an algorithm has order of complexity
O(n2)
119
The banker’s algorithm
• The resource allocation graph algorithm
doesn’t handle multiple instances of each
resource type
• The banker’s algorithm does
• This algorithm is as exciting as its name would
imply
120
• The banker’s algorithm basically consists of a
bunch of bookkeeping, using matrices to
manage the granting of multiple resources to
multiple processes
• It’s messy to do, but there is nothing cosmic
about the idea
• I’m not covering it
121
7.6 Deadlock Detection
• The second of the three major approaches to
handling deadlock was to implement
synchronization protocols so that deadlock
can be fixed if it does happen
• If you don’t do deadlock prevention or
deadlock avoidance, then you allow deadlocks
122
• At this point, if you choose to handle
deadlocks, two capabilities are necessary:
– 1. Deadlock detection
– 2. Deadlock recovery
• This is distinct from the third major approach,
simply ignoring deadlocks, which will be
discussed after this section
123
Detecting deadlocks with single
instances of resource types
• The first thing you need is the ability to detect
deadlocks in a system
• This can be done with a wait-for-graph
• This is like a resource allocation graph, but it’s not
necessary to record the resources
• Concretely, the O/S, in addition to its other
features, would be maintaining the wait-forgraph as one of the system resources, keeping it
up to date as resources are granted to processes
124
• The key information in a wait-for-graph is
whether one process is waiting on another
• A cycle in the graph still indicates deadlock
• A simple illustration of a resource allocation
graph and a comparable wait-for-graph is
given on the following overhead
125
126
• Wait-for-graph (WFG) algorithm
implementation
• 1. The system maintains a WFG, adding and
removing edges with requests and releases
• 2. The system periodically searches the graph
for cycles.
– This is O(n2), where n is the number of vertices
127
Several instances of a resource type
• This is analogous to the banker’s algorithm
• Instead of a WFG, it’s necessary to maintain
some NxM data structures and algorithms
• I am uninterested in the details
128
Deadlock detection algorithm usage
• When should deadlock detection be invoked?
• This depends on two questions:
– 1. How often is deadlock likely to occur?
– 2. How many processes are likely to be involved?
• The general answer is, the more likely you are
to have deadlock, and the worse it’s likely to
be, the more often you should check
129
• Checking for deadlock is a trade-off
• Checking isn’t computationally cheap
• Checking the complete WFG every time a
resource request can’t be satisfied would be
the greatest possible frequency for checking
it.
• This would be extreme
130
• However, in a real system deadlock might be a
significant problem which happens relatively
frequently.
• It would not be wise to check for deadlock too
infrequently.
• A system administrator might have a historical
record of the frequency of deadlocks.
• It might be advisable to check for deadlocks on a
schedule more frequent than the historical
record.
131
• Overall, deadlock will tend to affect system
performance because deadlock will prevent
processes from proceeding
• In practice, deadlock detection might be
triggered when some performance parameter
falls below a certain value, for example, CPU
utilization < 40%
• The system might be coded to do this
automatically, or this might be something that
the administrator does on a special case basis
132
7.7 Recovery from Deadlock
• Just like deadlock detection, deadlock
recovery may be an automatic feature built
into a deadlock handling system
• It may also be manual, done using system
utilities on a special case basis by the
administrator
133
• Overall, deadlock recovery falls into two
possible categories:
– 1. Abort processes to break cycles in the WFG
– 2. Pre-empt resources from processes to break
cycles without aborting
134
Process termination (abortion)
• There are basically two approaches:
– 1. Abort all deadlocked processes.
– 2. Abort one process at a time among those that
are deadlocked
• Approach 1 has the disadvantage that it
wastes a lot of work that was already done
135
• Approach 2 also has disadvantages
– The underlying problem is that there may be >1
cycle
– The cycles may be independent or they may share
processes
– In any case, killing a single process may not break
all cycles in the system
– If one process at a time is aborted, deadlock
detection will have to be done after each abortion
to see whether the system is deadlock free
136
• The overall problem with abortion is the potential
for leaving resources in an inconsistent state
• If abortion is supported, then all changes made
by a process should be individually logged
• Then if a partially finished process is aborted, an
advanced system will roll back all of the changes
that the process had made
• That is, abortion isn’t complete until there is no
trace of the process’s existence left
137
• Aside from the general question of rollback, if
selective abortion is done under approach 2,
then there need to be criteria for picking a
victim.
• Examples of criteria for picking victims:
– Process priority
– Time already spent computing, time remaining (%
completion)
138
• Process abortion criteria, continued:
– What resources are held
– How many more resources are needed? (%
completion as measured by resources)
– How many other processes will need to be
terminated?
– Whether the process is interactive or batch…
139
Resource pre-emption instead of full
abortion
• This is an even finer scalpel than abortion
• Three questions exist for pre-emption that are
essentially the same as for abortion:
• 1. Victim selection:
– How do you choose a victim for pre-emption
(what cost function)?
140
• 2. Rollback:
– In what way can you bring a partially finished
process back to a safe state where it could be
restarted and would run to completion correctly,
short of aborting it altogether?
• 3. Starvation:
– How do you make sure a single process isn’t
repeatedly pre-empted?
141
The third major approach
• The third of the three major approaches to
handling deadlock was to not implement any
particular protocols to handle deadlock
• Just ignore it
• If system performance tanks, you may or may
not suspect that deadlocks are to blame.
• In any case, without any better system tools,
the gross solution to the problem would just
be a restart.
142
The general topic of deadlock—again
• Consider the general principle illustrated by
deadlock
• The problem, deadlock, arises due to
concurrency
• The mindless “solution” to the problem is to
eliminate concurrency
143
• It is not possible to implement an operating
system without some form of concurrency
control.
• Therefore, deadlock is an inescapable
problem.
• The spectrum of solution approaches ranges
from ignoring it, to detecting and recovering
from it, to preventing it, to avoiding it
144
• The simplest way to deal with deadlock is to
ignore it.
• The hope is that deadlock is infrequent.
• If it does occur, whether you recognize it or
not, you overcome it by gross means, such as
rebooting
145
• Other solutions are more fine-grained, each
having its own implementation problems to
solve
• With detection and recovery you have to
maintain a graph and algorithms for detecting
cycles in it.
146
• With detection and recovery, you also have to
decide how fine-grained the recovery
mechanism is.
• How do you choose victims for abortion?
• Can rollback be implemented?
• Is it possible to pre-empt at the level of
individual resources rather than whole
processes?
147
• Rather than allowing deadlock to happen, you
can do deadlock prevention.
• This disallows one of the necessary conditions
for deadlock
• It severely affects concurrency
148
• One step further removed from deadlock
prevention is deadlock avoidance.
• Deadlock avoidance depends on not entering
an unsafe state
• This requires the maintenance and checking of
a graph when granting resources
• It trades greater implementation complexity
for a higher degree of concurrency
149
• This spectrum of implementation choices is broad
• As usual, choosing a solution involves a trade-off
• There is a cost to coding any given solution into
the operating system
• There is also a certain level of performance that
any given solution might give
• For any given system, with a certain kind of
workload and certain user expectations, the goal
is to implement a cost-effective solution to the
deadlock problem
150
The End
151