Chapter 6: Deadlock and Starvation

1
Chapter 6Deadlock and Starvation

• CS 472 Operating Systems
• Indiana University Purdue University Fort Wayne
• Mark Temte

2
Deadlock

• A common problem in concurrent applications
• Due to complex logic, design errors, etc.
• Three strategies exist for dealing with deadlock
• prevention
• detection
• avoidance

3
Deadlock

• Need to distinguish between consumable resources
  and reusable resources
• Consumable resources (resouce use consumes)
• rendezvous call, interrupt, input data item,
  etc.
• Reusable resources (not depleted)
• disk, printer, memory, CPU, file, etc.
• Reusable resources assume one user at a time

4
Modeling reusable resources

• Reusable resources can be modeled with a
  resource allocation and request graph

R1
process
P2
R3
R2
resources (3 copies available)
P1
P3
5
Necessary conditions for deadlock

• 1. mutual exclusion
• -- resources may be used only under mutual
  exclusion
• 2. hold-and-wait
• -- a process is allowed to hold resources
  while waiting for others
• 3. no pre-emption
• -- resources cannot be forcibly removed once
  granted to a process
• Deadlock cannot occur without all of these present

6
But more . . .

• These conditions are not sufficient for deadlock
• If there is deadlock, then some circular wait
  must exist
• In other words, 1, 2, 3, together with a circular
  wait are sufficient
• This is so whether resources are reusable or
  consumable
• Assumes multiple copies of resources are not
  available (more on this later)

7
Example of circular wait
printer
held by
request
A
B
disk
request
held by
Case of reusable resources
8
Example of circular wait
rendezvous A.Y( )
wait for call
wait to accept call
A
B
rendezvous B.X( )
wait for call
wait to accept call
Case of consumable resources
9
Deadlock prevention strategy

• Deny any of the three necessary conditions
• Or deny a circular wait from forming
• This is a very conservative strategy
• Note To deny mutual exclusion is usually off
  limits

10
Deadlock prevention deny hold-and-wait

• Widely used strategy
• Require a process to request all needed resources
  together
• Process must wait until all resources are
  available
• Problems
• No useful work possible with some resources while
  waiting for others
• Some resources may be tied up for some time after
  being allocated before they are used
• Process needs to be aware of all resource needs
  at all levels of modularity at time of request

11
Deadlock prevention deny no pre-emption

• Rarely used
• A process may be required to release a resource
  and request it again
• This is practical only if a resource can be
  easily restored to its state at the time of
  pre-emption
• Otherwise the OS must arrange to roll the process
  back to some saved earlier state
• Pre-emption of memory or of a processor is easy

12
Deadlock prevention deny circular wait

• Good method often used
• Order all resources and require that each process
  request resources in this order
• A circular wait cannot develop
• Method resembles a less-demanding version of
  denying hold-and-wait
• Established resource order needs to be determined
  carefully
• All resources need to be known in advance

13
Deadlock detection strategy

• The OS periodically checks for circular waits
• Periodically ?
• After each resource request
• After some amount of time
• For each circular wait found
• Terminate some / all of the deadlocked processes
• Roll back some / all processes to release
  resources
• Awkward and may lead to more deadlock

14
Deadlock detectionCase of reusable resources
with multiple copies

• More complicated situation than with single
  copies
• Here, circular waits may not be sufficient for
  deadlock
• To detect deadlock in this situation . . .
• First imagine eliminating any process that can be
  given all needed resources
• This is called a reduction
• Then free the resources of the eliminated process
• If all processes reduce, then there is no deadlock

15
Example several circular waits but no deadlock
Circular waits exist in this resource allocation
and request graph
A new request can be granted without deadlock
16
Deadlock avoidance strategy

• Process initiation denial
• A process is started only when the resource needs
  of existing processes together with the new
  process can be met
• This is not optimal and assumes all resources are
  needed simultaneously by all processes
• Resource allocation denial (bankers algorithm)
• A resource request is not granted if it allows
  the possibility of deadlock
• The algorithm uses the concept of a safe state

17
Safe State (bankers algorithm)

• A safe state means resources exist for all
  processes to complete in some order
• In the example earlier of circular waits with no
  deadlock, the system is in a safe state
• Another example 4 processes, 1 resource (8
  copies)

current maximum process allocation
needed 1 0 3
2 2 4 3 3
7 4 1 3 available
2
State is currently safe. The two available
copies can allow processes 2 or 4 to complete. If
process 3 requests a 4th copy, it should be
denied. The the state would become unsafe
(actually deadlocked).
18
Bankers algorithm

• More complicated example in text (pp.268-271)
• 4 processes, 3 resources with multiple copies
• Unsafe state but not deadlocked
• Just the potential for deadlock
• Disadvantages . . .
• Resource needs must be known in advance
• Available resources must be fixed
• Synchronization constraints cannot be mixed with
  resource constraints
• For example, due to message passing

19
Integrated deadlock strategy

• Group resources into classes
• Use deny circular wait among classes
• This prevents deadlocks among resource classes
• Use a class-specific strategy within each
  resource class
• See pp. 274-275 for an example