Operating Systems COMP 4850/CISG 5550

1
Operating SystemsCOMP 4850/CISG 5550

• Deadlock Avoidance
• Dr. James Money

2
Introduction to Deadlocks

• Deadlocks are formally defined by
• 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
• Since they are all waiting, none of them will
  wake up
• Assumption of no interrupts and single threads

3
Conditions for Deadlock

1. Mutual Exclusion each resource is either
   currently assigned to one process or is available
2. Hold and Wait processes currently holding
   resources can request new resources
3. No preemption Resources previously granted
   cannot forcibly be taken away from the process.
   They must be released by the process
4. Circular Wait there must be a circular chain of
   2 processes, each whom is waiting for a resource
   held by the next member of the chain

4
Conditions for Deadlock

• All four conditions must exist for a deadlock to
  occur
• If one is absent, deadlock cannot occur
• Many of these are related to system policy choices

5
Dealing with Deadlocks

• Ignore the problem, maybe it will ignore you?
• Used by UNIX and Windows
• Detection and Recovery
• Dynamic avoidance by careful resource allocation
• Prevention by structurally negating one of the
  four conditions for deadlocks

6
Deadlock Avoidance

• In deadlock detection, we assumed all resources
  were requested simultaneously
• However, in reality, we request them one at a
  time
• The system must decide if granting the resource
  is safe or not
• We consider careful resource allocation now

7
Resource Trajectories

• The main algorithm is based on the idea of safe
  states
• We first consider a graphic version of this model
  first
• The does not immediately turn into an algorithm,
  but provide a good intuition into the problem

8
Resource Trajectories

• The following slide shows a model for dealing
  with two processes and two resources
• The horizontal axis represents number of
  instructions executed for process A
• The vertical axis represents number of
  instructions executed for process B

9
Resource Trajectories

• At I1, A requests a printer and at I2, A requests
  a plotter
• The printer and plotter are released at I3 and
  I4, respectively
• Process B needs the plotter from I5 to I7 and the
  printer from I6 to I8

10
Resource Trajectories
11
Resource Trajectories

• Every point in the picture represents a joint
  state of the two processes
• Initially, the state is p, with nothing having
  been executed
• If the scheduler runs A first, then we get to
  point q
• Then process B runs, and we get to r

12
Resource Trajectories

• When A cross the line for I1, it requests and it
  granted the printer
• When B reaches t, it requests the plotter
• The shaded regions are of particular interest for
  deadlocks

13
Resource Trajectories

• The slanted lines from southwest to northeast is
  when both processes have the printer
• The slanted lines from northwest to southeast is
  when both processes have the plotter
• Both of these are deadlock regions because of
  mutual exclusion

14
Resource Trajectories

• If the system enters the box bounded by I1, I2,
  I5, and I6, it will eventually deadlock when it
  reaches the intersection of I2 and I6
• The entire box is unsafe
• At point t, the only safe course of action is to
  run process A until it gets to I4
• Any trajectory outside of this box to u will do

15
Resource Trajectories

• The important thing to notice at point t, is that
  process B is requesting a resource
• The system must decide to grant it or not
• If it is granted, it enters an unsafe region and
  a possible deadlock
• To avoid this, we should suspect process A until
  is requests and releases the plotter

16
Safe and Unsafe States

• We will use the vectors and matrices from
  deadlock detection
• A state is said to be safe if it is not
  deadlocked and there is some scheduling order so
  that each process can run to completion even if
  they requests their maximum number of resources
  immediately

17
Safe and Unsafe States
18
Safe and Unsafe States
19
Safe and Unsafe States

• The prior example is safe since there is a
  sequence of allocations that allows the processes
  to complete
• Now, let us consider an unsafe example

20
Safe and Unsafe States
21
Safe and Unsafe States

• So, the decision to go from (a) to (b) in the
  prior slide moves us from a safe state to an
  unsafe state
• We should have not granted process As request to
  prevent a possible deadlock
• Note An unsafe state is not necessarily a
  deadlock!
• Only a safe state guarantees all processes will
  finish
• In an unsafe state, it may or may not finish

22
Bankers Algorithm for Single Resource

• The scheduling algorithm for handling single
  resources is due to Dijkstra(1965) and is known
  as the bankers algorithm
• It is an extension of the deadlock detection
  algorithm
• It is modeled similar to the way a small town
  banker deals with customers whom he has given a
  line of credit

23
Bankers Algorithm for Single Resource

• The algorithm checks to see if granting a
  resource leads to a safe or unsafe state
• The banker gives out the various credit limits,
  which add up to 22
• However, s/he can only lend out 10 units at a
  time
• The units can be tape drives, the customers are
  processes and the banker is the OS

24
Bankers Algorithm for Single Resource
25
Bankers Algorithm for Single Resource

• In (b), the state is safe
• In (c) is unsafe
• In (b), if anyone but C requests a resource, it
  can be delayed until C is finished
• (c) does not have to result in a deadlock, but we
  want to avoid this state

26
Bankers Algorithm for Single Resource

• The algorithm considers each request as it occurs
  and checks to see if it leads to a safe state
• If it does, the request is granted
• If it does not, the request is postponed
• To check safety, we see if we have enough
  resources to satisfy some process
• The resources are released, and the next closest
  customer of the limit is checked, and so on
• All processes must be able to finish to be safe

27
Bankers Algorithm for Multiple Resources

• We can now generalize the bankers algorithm for
  multiple resources
• This time we use a matrix of assigned and request
  resources similar to before

28
Bankers Algorithm for Multiple Resources
29
Bankers Algorithm for Multiple Resources

1. Look at a row, R, whose unmet resource needs are
   smaller than or equal to A(RltA). If no row
   exists, the system will eventually deadlock
2. Assume the process of the chosen row requests its
   resources and finishes. Mark the process as
   terminated and add its resources to vector A
3. Repeat 1 and 2 until either all the processes are
   marked as terminated, which means the state is
   safe, or until a deadlock occurs, which means the
   state is unsafe

30
Bankers Algorithm for Multiple Resources

• The current state is safe in the figure
• Suppose process B requests a scanner
• This is granted since the resulting state is safe
• Process D, then process A or E finishes, followed
  by the rest

31
Bankers Algorithm for Multiple Resources

• After B is granted one of the two remaining
  scanners, suppose E wants the last printer
• This reduces A(1 0 0 0)
• This leads to a potential deadlock
• This request must be deferred

32
Houston, we have a problem!

• This has been highly studied
• However, it suffers from a major flaw
• It is useless
• It needs to know the total resource needs of a
  program in advance
• In addition, the number of processes is dynamic