Deadlocks

1
Deadlocks

• Chapter 3

3.1. Resource 3.2. Introduction
to deadlocks 3.3. The ostrich algorithm
3.4. Deadlock detection and recovery
3.5. Deadlock avoidance 3.6.
Deadlock prevention 3.7. Other issues
2
Resources

• Examples of computer resources
• printers
• tape drives
• tables
• Processes need access to resources in reasonable
  order
• Suppose a process holds resource A and requests
  resource B
• at same time another process holds B and requests
  A
• both are blocked and remain so
• Hardware and software deadlocks

3
Resources

• Deadlocks occur when
• processes are granted exclusive access to devices
• we refer to these devices generally as resources
• Resources may have multiple copies
• Preemptable resources
• can be taken away from a process with no ill
  effects (for example memory)
• Nonpreemptable resources
• will cause the process to fail if taken away
  (e.g. CDR)

4
Resources

• Sequence of events required to use a resource
• request the resource
• use the resource
• release the resource
• Must wait if request is denied
• requesting process may be blocked
• may fail with error code
• Nature of requesting a resource is highly system
  dependent (e.g. request system call)

5
Resource Acquisition
t
6
Introduction to Deadlocks

• Formal definition 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
• None of the processes can
• run
• release resources
• be awakened
• Number of processes and resources is unimportant

7
Introduction to Deadlocks

• Different from starvation and livelock
• Starvation one process is active, but never
  gets the resource
• Livelock all processes starve

8
Four Conditions for Deadlock

• Mutual exclusion condition
• Each resource assigned to 1 process or is
  available
• Hold and wait condition
• Process holding resources can request additional
• No preemption condition
• Assigned resources cannot be involuntarily
  claimed
• Circular wait condition
• Must be a circular chain of 2 or more processes
• Each is waiting for resource held by next member
  of the chain

9
Dealing with Deadlocks

• Strategies
• Just ignore the problem altogether (Ostrich Alg.)
• Allow deadlock, detect it, break it
• Prevention
• Negate one of the four necessary conditions
• Dynamic avoidance
• Careful resource allocation each resource
  request is analyzed and denied if deadlock might
  result

10
The Ostrich Algorithm

• Pretend there is no problem
• Reasonable if
• deadlocks occur very rarely
• cost of prevention is high
• UNIX and Windows takes this approach
• It is a trade off between
• convenience
• correctness

11
Deadlock Prevention Avoidance

• Deadlock prevention
• Define a global ordering of all resources
• Each process locks resources in order
• Resource can be unlocked at any time
• Useful within multi-threaded programs
• Deadlock avoidance Bankers Algorithm

12
Detection Deadlock Modeling

• Modeled with directed graphs
• resource R assigned to process A
• process B is requesting/waiting for resource S
• process C and D are in deadlock over resources T
  and U

13
Deadlock Modeling
A B
C

• How deadlock occurs

14
Detection with One Resource of Each Type

• AG processes RW resources
• Note the resource ownership and requests
• Is this system deadlocked and if yes, which
  processes are involved?
• A cycle can be found within the graph, denoting
  deadlock

15
Detection with One Resource of Each Type

• We need a formal algorithm for detecting
  deadlocks
• A simple one to detect cycles
• Use resource graph
• Perform DFS (depth first search) starting at each
  node, looking for cycles (recurrence of starting
  node)
• If it comes to a node it has encountered in this
  run, then there exists a cycle.
• Why use DFS and not BFS?
• Review DFS vs. BFS.

16
Pseudocode for Deadlock Detection

• For i1 to N nodes
• reset graph to unmarked
• L empty list
• traverse_graph (nodei)

traverse_graph (node) add node to L check
for cycle in L if (there exists outgoing
unmarked arcs from node) mark
node-gtoutgoing traverse_graph
(node-gtoutgoing)
17
Detection Time Complexity

• N nodes, E arcs
• Time complexity for DFS is O (N E)
• Need to do DFS N times (once for each node)
• O (N (N E))
• Check for cycles
• Simple way can check every node visited to see
  if it is equal to root O(1) complexity
• Better check for any cycle in branch worse
  case O (N )
• Total complexity
• O (N (N E) N ) O (2N NE) O (N NE)
• N ltlt E, so N ltlt N E, total complexity is O (NE)

2
2
2
2
2
18
Detection How often to run?

• After every allocation of resource is too
  expensive
• Every few minutes
• When CPU is idle indication of blocked
  processes waiting for resources

19
Detection with Multiple Resources of Each Type

• Basic idea Allocate resources to a process that
  can be run to completion
• 4 data structures
• Vector of resources in existence
• E of resource i in system
• Vector of available resources,
• A of available resource i
• Allocation matrix
• C of resource j that are being held by
  process i
• Request matrix
• R of resource j that are requested by
  process i

i
i
ij
ij
20
Detection with Multiple Resources of Each Type
n

• Invariant property Si1Cij Aj Ej

21
Detection with Multiple Resources of Each Type

• Deadlock detection is based on comparing vectors
• Algorithm
• Look for an unmarked process, Pi for which the
  i-th row of R is less or equal to A
• If such a process is found, add the i-th row of C
  to A, mark the process and go back to step 1
• If no such process exists the algorithm terminates

22
Detection with Multiple Resources of Each Type

• Unmark all processes
• While (there exists unmarked processes)
• for i 1to n processes
• can_satisfy TRUE
• for j 1 to r resources
• if (Rij gt Aj)
• can_satisfy FALSE
• break
• if (can_satisfy)
• for j 1 to r resources // Release
  resources since alloted to process i
• Aj Cij // process i can finish and release
  its resources
• mark process

23
Detection with Multiple Resources of Each Type

• An example for the deadlock detection algorithm
• (3/2/1)

24
Recovery from Deadlock

• Recovery through preemption
• Take a resource from some process to allow others
  to complete
• Depends on nature of the resource
• Recovery through rollback
• Checkpoints are written to a file and include
  memory image, resource state, and other state
  variables
• Lose work that was done after checkpoint since
  roll back returns machine back to checkpoint
  state
• Checkpoints are considered safe states
• Total rollback means that no safe state existed
  restart process
• Kill process to release resources
• Need to make sure process can be started again
  later w/o ill effects

25
Recovery from Deadlock

• Abort all deadlocked processes
• Expensive lose data and results of computation
• Deadlock may occur again if all processes
  restarted
• Abort one process at a time until no deadlock
• Lots of overhead after each process is aborted,
  must do detection again
• Which process to abort?
• Abort the one that incurs minimal cost
• Factors priority, how long process has run,
  type of resource process has, requested
  resources, type of process

26
Deadlock Prevention Attack 4 Deadlock Conditions

• Condition Approach Problem
• Mutual -Spooling exp. only printer -Not all
  devices can be spooled
• Exclusion daemon requests printer Competition
  for spooler space
• can become deadlocked
• Hold Wait -Require all processes to
• Condition request all resources before
• running (then, can use Bankers)
• -Allow processes access to only -Not
  practical for some cases
• 1 resource at a time. (exp. Copy between 2
  disks)
• No Preemption -Allow preemption -Not viable for
  some resources
• (exp. Printers)
• Circular Wait -Order resources numerically -There
  may be too many
• Processes must make requests resources to
  numerically order
• in order. (database tables, for exp.)

27
Deadlock PreventionAttacking the Mutual
Exclusion Condition

• Some devices (such as printer) can be spooled
• only the printer daemon uses printer resource
• thus deadlock for printer eliminated
• Not all devices can be spooled
• Principle
• avoid assigning resource when not absolutely
  necessary
• as few processes as possible actually claim the
  resource

28
Attacking the Hold and Wait Condition

• Goal Prevent processes that hold resources from
  waiting for more resources
• Require processes to request resources before
  starting
• a process never has to wait for what it needs
• Problems
• may not know required resources at start of run
• also ties up resources other processes could be
  using
• Variation
• process must give up temporarily all resources
  before requesting a new one
• then request all immediately needed

29
Attacking the No Preemption Condition

• This is not a viable option
• Consider a process given the printer
• halfway through its job
• now forcibly take away printer
• !!??

30
Attacking the Circular Wait Condition
(a)
(b)

• Normally ordered resources
• A resource graph

31
Attacking the Circular Wait Condition

• Rule All requests of a process must be made in
  numerical order gt the resource allocation graph
  can not have cycles
• Either i lt j or i gt j gt cant have deadlocks
• Same logic with multiple resources at every
  instant one assigned resource will be the highest
• Problem impossible to find an ordering to
  satisfy everyone

32
Deadlock Avoidance

• So far we assumed that all requests take place at
  the beginning
• The system must be able to decide whether
  granting a resource request is safe or not
• Is there an algorithm that can always avoid
  deadlocks?
• Yes, if certain information is known in advance

33
State of Resource Allocation Safe Unsafe States

• Safe
• System is not deadlocked and can guarantee that
  all processes will finish. There is some
  scheduling order such that all processes finish.
  
• Unsafe
• System may not be deadlocked, but cannot
  guarantee that all processes can finish
• No scheduling order that guarantees all processes
  will finish, but process may be lucky and finish
  due to some processes releasing resources early

34
Determining Safe/Unsafe Using Bankers Alg.

• Similar to deadlock detection
• Consider each request as it occurs and see if
  granting it leads to a safe state
• If a granting a resource leads to a deadlock
  cycle, then state is unsafe and do not grant
• Key assumptions
• All processes need to declare their max resources
  
• of processes and resources are fixed. Need to
  dynamically update resource allocation table for
  entering/exiting processes to handle dynamic
  environment

35
Determining Safe Unsafe States

• Use resource allocation table
• Examples for a single resource. Can be scaled to
  multiple resources
• Proc. Has Max (Needs) Proc. Has Max (Needs)
• A 3 9 6 A 4 9 5
• B 2 4 2 B 2 4 2
• C 2 7 5 C 2 7 5
• Free 3 Free 2
• What is the difference between detection alg. And
  Bankers?

36
Other IssuesTwo-Phase Locking

• Deadlock avoidance and prevention are difficult
  to use in practice for large dynamic systems
• Detection and recovery is more practical
• Two-phase locking is practical solution often
  used in databases
• Phase 1
• process tries to lock all records it needs, one
  at a time
• if needed record found locked, start over
• (no real work done in phase one)
• If phase 1 succeeds, start phase 2
• perform updates
• release locks
• Note similarity to requesting all resources at
  once
• Applicable in small-scale, such as process that
  updates a few records in a few tables
• Not useful for processes where release and
  restart is not possible

37
Non-resource Deadlocks

• Possible for two processes to deadlock
• Each is waiting for the other to do some task
• Can happen with semaphores
• Each process required to do a down() on two
  semaphores (mutex and another)
• If done in wrong order, deadlock results
• Solution is more careful programming