CS 471 Lecture 3 Process Synchronization

1
CS 471 - Lecture 3Process Synchronization
Deadlock

• Ch. 6 (6.1-6.7), 7
• Fall 2009

2
Process Synchronization

• Race Conditions
• The Critical Section Problem
• Synchronization Hardware
• Classical Problems of Synchronization
• Semaphores
• Monitors
• Deadlock

3
Concurrent Access to Shared Data

• Suppose that two processes A and B have access to
  a shared variable Balance.
• PROCESS A PROCESS
  B
• Balance Balance - 100 Balance
  Balance 200
• Further, assume that Process A and Process B are
  executing concurrently in a time-shared,
  multi-programmed system.

4
Concurrent Access to Shared Data

• The statement Balance Balance 100 is
  implemented by several machine level instructions
  such as
• A1. lw t0, BALANCE
• A2. sub t0,t0,100
• A3. sw t0, BALANCE
• Similarly, Balance Balance 200 can be
  implemented by the following
• B1. lw t1, BALANCE
• B2. add t1,t1,200
• B3. sw t1, BALANCE

5
Race Conditions

• Observe In a time-shared system the exact
  instruction execution order cannot be predicted

• Scenario 1
• A1. lw t0, BALANCE
• A2. sub t0,t0,100
• A3. sw t0, BALANCE
• Context Switch
• B1. lw t1, BALANCE
• B2. add t1,t1,200
• B3. sw t1, BALANCE
• Balance is increased by 100

• Scenario 2
• A1. lw t0, BALANCE
• A2. sub t0,t0,100
• Context Switch
• B1. lw t1, BALANCE
• B2. add t1,t0,200
• B3. sw t1, BALANCE
• Context Switch
• A3. sw t0, BALANCE
• Balance is decreased by 100

6
Race Conditions

• Situations where multiple processes are writing
  or reading some shared data and the final result
  depends on who runs precisely when are called
  race conditions.
• A serious problem for most concurrent systems
  using shared variables! Maintaining data
  consistency requires mechanisms to ensure the
  orderly execution of cooperating processes.
• We must make sure that some high-level code
  sections are executed atomically.
• Atomic operation means that it completes in its
  entirety without worrying about interruption by
  any other potentially conflict-causing process.

7
The Critical-Section Problem

• n processes all competing to use some shared data
• Each process has a code segment, called critical
  section (critical region), in which the shared
  data is accessed.
• Problem ensure that when one process is
  executing in its critical section, no other
  process is allowed to execute in their critical
  section.
• The execution of the critical sections by the
  processes must be mutually exclusive in time.

8
Mutual Exclusion
9
Solving Critical-Section Problem

• Any solution to the problem must satisfy three
  conditions.
• Mutual Exclusion
• No two processes may be simultaneously inside
  the same critical section.
• Bounded Waiting
• No process should have to wait forever to enter
  a critical section.
• Progress
• No process executing a code segment
  unrelated to a given critical section can
  block another process trying to enter the
  same critical section.
• Arbitrary Speed
• In addition, no assumption can be made about
  the relative speed of different processes (though
  all processes have a non-zero speed).

10
Attempts to solve mutual exclusion

• do
• .
• entry section
• critical section
• exit section
• remainder section
• while (1)
• General structure as above
• Two processes P1 and P2
• Processes may share common variables
• Assume each statement is executed atomically (is
  this realistic?)

11
Algorithm 1

• Shared variables
• int turn initially turn 0
• turn i ? Pi can enter its critical section
• Process Pi
• do
• while (turn ! i) //it can be forever
• critical section
• turn j
• reminder section
• while (1)
• Satisfies mutual exclusion, but not progress

busy waiting
12
Algorithm 2

• Shared variables
• boolean flag2 initially flag0 flag1
  false
• flagi true ? Pi wants to enter its critical
  region
• Process Pi
• do
• flagitrue
• while (flagj) //Pi Pj both waiting
• critical section
• flagi false
• reminder section
• while (1)
• Satisfies mutual exclusion, but not progress

13
Algorithm 3 Petersons solution

• Combine shared variables of previous attempts
• Process Pi
• do
• flagitrue
• turn j
• while (flagj and turn j)
• critical section
• flagi false
• reminder section
• while (1)
• Meets our 3 requirements (assuming each
  individual statement is executed atomically)

flagj false or turn i
14
Synchronization Hardware

• Many machines provide special hardware
  instructions that help to achieve mutual
  exclusion
• The TestAndSet (TAS) instruction tests and
  modifies the content of a memory word atomically
• TAS R1,LOCK reads the contents of the memory
  word LOCK into register R1, and stores a nonzero
  value (e.g. 1) at the memory word LOCK
  (atomically)
• Assume LOCK 0
• calling TAS R1, LOCK will set R1 to 0, and set
  LOCK to 1.
• Assume LOCK 1
• calling TAS R1, LOCK will set R1 to 1, and set
  LOCK to 1.

15
Mutual Exclusion with Test-and-Set

• Initially, shared memory word LOCK 0.
• Process Pi
• do
• entry_section
• TAS R1, LOCK
• CMP R1, 0 / was LOCK 0? /
• JNE entry_section
• critical section
• MOVE LOCK, 0 / exit section /
• remainder section
• while(1)

16
Classical Problems of Synchronization

• Producer-Consumer Problem
• Readers-Writers Problem
• Dining-Philosophers Problem
• We will develop solutions using semaphores and
  monitors as synchronization tools (no busy
  waiting).

17
Producer/Consumer Problem
Producer
Consumer
bounded size buffer (N)

• Producer and Consumer execute concurrently but
  only one should be accessing the buffer at a
  time.
• Producer puts items to the buffer area but
  should not be allowed to put items into a full
  buffer
• Consumer process consumes items from the buffer
  but cannot remove information from an empty buffer

18
Readers-Writers Problem

• A data object (e.g. a file) is to be shared among
  several concurrent processes.
• A writer process must have exclusive access to
  the data object.
• Multiple reader processes may access the shared
  data simultaneously without a problem
• Several variations on this general problem

19
Dining-Philosophers Problem
Five philosophers share a common circular table.
There are five chopsticks and a bowl of rice (in
the middle). When a philosopher gets hungry, he
tries to pick up the closest chopsticks. A
philosopher may pick up only one chopstick at a
time, and cannot pick up a chopstick already in
use. When done, he puts down both of his
chopsticks, one after the other.
20
Synchronization

• Synchronization
• Most synchronization can be regarded as either
• Mutual exclusion (making sure that only one
  process is executing a CRITICAL SECTION touching
  a variable or data structure, for example at a
  time), or as
• CONDITION SYNCHRONIZATION, which means making
  sure that a given process does not proceed until
  some condition holds (e.g. that a variable
  contains a given value)
• The sample problems will illustrate this

Competition
Cooperation
21
Semaphores

• Language level synchronization construct
  introduced by E.W. Dijkstra (1965)
• Motivation Avoid busy waiting by blocking a
  process execution until some condition is
  satisfied.
• Each semaphore has an integer value and a queue.
• Two operations are defined on a semaphore
  variable s
• wait(s) (also called P(s) or
  down(s))
• signal(s) (also called V(s) or
  up(s))
• We will assume that these are the only
  user-visible operations on a semaphore.
• Semaphores are typically available in thread
  implementations.

22
Semaphore Operations

• Conceptually a semaphore has an integer value
  greater than or equal to 0.
• wait(s) wait/block until s.value gt 0
  s.value-- / Executed atomically! /
• A process executing the wait operation on a
  semaphore with value 0 is blocked (put on a
  queue) until the semaphores value becomes
  greater than 0.
• No busy waiting
• signal(s) s.value / Executed atomically!
  /

23
Semaphore Operations (cont.)

• If multiple processes are blocked on the same
  semaphore s, only one of them will be awakened
  when another process performs signal(s)
  operation. Who will have priority?
• Binary semaphores only have value 0 or 1.
• Counting semaphores can have any non-negative
  value. We will see some of these later

24
Critical Section Problem with Semaphores

• Shared data
• semaphore mutex / initially mutex 1 /
• Process Pi do wait(mutex)
  critical section
• signal(mutex) remainder section
  while (1)

25
Re-visiting the Simultaneous Balance Update
Problem

• Shared data int Balance
• semaphore mutex // initially mutex 1

• Process A
• .
• wait (mutex)
• Balance Balance 100
• signal (mutex)

• Process B
• .
• wait (mutex)
• Balance Balance 200
• signal (mutex)

26
Semaphore as a General Synchronization Tool

• Suppose we need to execute B in Pj only after A
  executed in Pi
• Use semaphore flag initialized to 0
• Code
• Pi Pj
• ? ?
• A wait(flag)
• signal(flag) B

27
Returning to Producer/Consumer
Producer
Consumer
bounded size buffer (N)

• Producer and Consumer execute concurrently but
  only one should be accessing the buffer at a
  time.
• Producer puts items to the buffer area but
  should not be allowed to put items into a full
  buffer
• Consumer process consumes items from the buffer
  but cannot remove information from an empty buffer

28
Producer-Consumer Problem (Cont.)

• Make sure that
• The producer and the consumer do not access the
  buffer area and related variables at the same
  time.
• No item is made available to the consumer if all
  the buffer slots are empty.
• No slot in the buffer is made available to the
  producer if all the buffer slots are full.

competition
cooperation
29
Producer-Consumer Problem

• Shared datasemaphore full, empty,
  mutexInitiallyfull 0 / The number of
  full buffers /
• empty n / The number of empty buffers /
• mutex 1 / Semaphore controlling the
  access to the buffer pool /

binary
counting
30
Producer Process

• do
• produce an item in p
• wait(empty)
• wait(mutex)
• add p to buffer
• signal(mutex)
• signal(full)
• while (1)

31
Consumer Process

• do
• wait(full)
• wait(mutex)
• remove an item from buffer to c
• signal(mutex)
• signal(empty)
• consume the item in c
• while (1)

32
Readers-Writers Problem

• A data object (e.g. a file) is to be shared among
  several concurrent processes.
• A writer process must have exclusive access to
  the data object.
• Multiple reader processes may access the shared
  data simultaneously without a problem
• Shared datasemaphore mutex, wrt
• int readcount Initiallymutex 1, readcount
  0, wrt 1

33
Readers-Writers Problem Writer Process

• wait(wrt)
• writing is performed
• signal(wrt)

34
Readers-Writers Problem Reader Process

• wait(mutex)
• readcount
• if (readcount 1)
• wait(wrt)
• signal(mutex)
• reading is performed
• wait(mutex)
• readcount--
• if (readcount 0)
• signal(wrt)
• signal(mutex)

Is this solution o.k.?
35
Dining-Philosophers Problem
Five philosophers share a common circular table.
There are five chopsticks and a bowl of rice (in
the middle). When a philosopher gets hungry, he
tries to pick up the closest chopsticks. A
philosopher may pick up only one chopstick at a
time, and cannot pick up a chopstick already in
use. When done, he puts down both of his
chopsticks, one after the other.

• Shared data
• semaphore chopstick5
• Initially all semaphore values are 1

36
Dining-Philosophers Problem

• Philosopher i
• do
• wait(chopsticki)
• wait(chopstick(i1) 5)
• eat
• signal(chopsticki)
• signal(chopstick(i1) 5)
• think
• while (1)

Is this solution o.k.?
37
Semaphores

• It is generally assumed that semaphores are fair,
  in the sense that processes complete semaphore
  operations in the same order they start them
• Problems with semaphores
• They're pretty low-level.
• When using them for mutual exclusion, for example
  (the most common usage), it's easy to forget a
  wait or a release, especially when they don't
  occur in strictly matched pairs.
• Their use is scattered.
• If you want to change how processes synchronize
  access to a data structure, you have to find all
  the places in the code where they touch that
  structure, which is difficult and error-prone.
• Order Matters
• What could happen if we switch the two wait
  instructions in the consumer (or producer)?

38
Deadlock and Starvation

• Deadlock two or more processes are waiting
  indefinitely for an event that can be caused by
  only one of the waiting processes.
• Let S and Q be two semaphores initialized to 1
• P0 P1
• wait(S) wait(Q)
• wait(Q) wait(S)
• M M
• signal(S) signal(Q)
• signal(Q) signal(S)
• Starvation indefinite blocking. A process may
  never be removed from the semaphore queue in
  which it is suspended.

39
High Level Synchronization Mechanisms

• Several high-level mechanisms that are easier to
  use have been proposed.
• Monitors
• Critical Regions
• Read/Write locks
• We will study monitors (Java and Pthreads provide
  synchronization mechanisms based on monitors)
• They were suggested by Dijkstra, developed more
  thoroughly by Brinch Hansen, and formalized
  nicely by Tony Hoare in the early 1970s
• Several parallel programming languages have
  incorporated some version of monitors as their
  fundamental synchronization mechanism

40
Monitors

• A monitor is a shared object with operations,
  internal state, and a number of condition queues.
  Only one operation of a given monitor may be
  active at a given point in time
• A process that calls a busy monitor is delayed
  until the monitor is free
• On behalf of its calling process, any operation
  may suspend itself by waiting on a condition
• An operation may also signal a condition, in
  which case one of the waiting processes is
  resumed, usually the one that waited first

41
Monitors

• Condition (cooperation) Synchronization with
  Monitors
• Access to the shared data in the monitor is
  limited by the implementation to a single process
  at a time therefore, mutually exclusive access
  is inherent in the semantic definition of the
  monitor
• Multiple calls are queued

• Mutual Exclusion (competition) Synchronization
  with Monitors
• delay takes a queue type parameter it puts the
  process that calls it in the specified queue and
  removes its exclusive access rights to the
  monitors data structure
• continue takes a queue type parameter it
  disconnects the caller from the monitor, thus
  freeing the monitor for use by another process.
  It also takes a process from the parameter queue
  (if the queue isnt empty) and starts it

42
Shared Data with Monitors

• Monitor SharedData
• int balance
• void updateBalance(int amount)
• int getBalance()
• void init(int startValue) balance
  startValue
• void updateBalance(int amount) balance
  amount
• int getBalance() return balance

43
Monitors

• To allow a process to wait within the monitor, a
  condition variable must be declared, as
• condition x, y
• Condition variable can only be used with the
  operations wait and signal.
• The operation
• x.wait()means that the process invoking this
  operation is suspended until another process
  invokes
• x.signal()
• The x.signal operation resumes exactly one
  suspended process on condition variable x. If no
  process is suspended on condition variable x,
  then the signal operation has no effect.
• Wait and signal operations of the monitors are
  not the same as semaphore wait and signal
  operations!

44
Monitor with Condition Variables

• When a process P signals to wake up the process
  Q that was waiting on a condition, potentially
  both of them can be active.
• However, monitor rules require that at most one
  process can be active within the monitor. Who
  will go first?
• Signal-and-wait P waits until Q leaves the
  monitor (or, until Q waits for another
  condition).
• Signal-and-continue Q waits until P leaves the
  monitor (or, until P waits for another
  condition).
• Signal-and-leave P has to leave the monitor
  after signaling (Concurrent Pascal)
• The design decision is different for different
  programming languages

45
Monitor with Condition Variables
46
Producer-Consumer Problem with Monitors

• Monitor Producer-consumer
• condition full, empty
• int count
• void insert(int item) //the following slide
• int remove() //the following slide
• void init()
• count 0

47
Producer-Consumer Problem with Monitors (Cont.)

• void insert(int item)if (count N)
  full.wait()
• insert_item(item) // Add the new item
  count if (count 1) empty.signal()
• int remove() int mif (count 0)
  empty.wait()m remove_item() // Retrieve one
  itemcount --if (count N1) full.signal()
• return m

48
Producer-Consumer Problem with Monitors (Cont.)

• void producer() //Producer process while
  (1)
• item Produce_Item()
• Producer-consumer.insert(item)
• void consumer() //Consumer process while
  (1)
• item
• Producer-consumer.remove(item)
• consume_item(item)

49
Monitors

• Evaluation of monitors
• Strong support for mutual exclusion
  synchronization
• Support for condition synchronization is very
  similar as with semaphores, so it has the same
  problems
• Building a correct monitor requires that one
  think about the "monitor invariant. The monitor
  invariant is a predicate that captures the notion
  "the state of the monitor is consistent."
• It needs to be true initially, and at monitor
  exit
• It also needs to be true at every wait statement
• Can implement monitors in terms of semaphores ?
  that semaphores can do anything monitors can.
• The inverse is also true it is trivial to build
  a semaphores from monitors

50
Dining-Philosophers Problem with Monitors

• monitor dp
• enum thinking, hungry, eating state5
• condition self5
• void pickup(int i) // following slides
• void putdown(int i) // following slides
• void test(int i) // following slides
• void init()
• for (int i 0 i lt 5 i)
• statei thinking

Each philosopher will perform dp.
pickup (i) eat.. dp. putdown(i)
51
Solving Dining-Philosophers Problem with Monitors

• void pickup(int i)
• statei hungry
• test(i)
• if (statei ! eating)
• selfi.wait()
• void putdown(int i)
• statei thinking
• // test left and right neighbors
• // wake them up if possible
• test((i4) 5)
• test((i1) 5)

52
Solving Dining-Philosophers Problem with Monitors

• void test(int i)
• if ( (state(i 4) 5 ! eating)
• (statei hungry)
• (state(i 1) 5 ! eating))
• statei eating
• selfi.signal()

Is this solution o.k.?
53
Dining Philosophers problem (Cont.)

• Philosopher1 arrives and starts eating
• Philosopher2 arrives he is suspended
• Philosopher3 arrives and starts eating
• Philosopher1 puts down the chopsticks, wakes up
  Philosopher2 (suspended once again)
• Philosopher1 re-arrives, and starts eating
• Philosopher3 puts down the chopsticks, wakes up
  Philosopher2 (suspended once again)
• Philosopher3 re-arrives, and starts eating

54
Deadlock

• In a multi-programmed environment,
  processes/threads compete for (exclusive) use of
  a finite set of resources

55
Necessary Conditions for Deadlock

• Mutual exclusion At least one resource must be
  held in a non-sharable mode
• Hold and wait A process holds at least one
  resource while waiting to acquire additional
  resources that are being held by other processes
• No preemption a resource is only released
  voluntarily from a process
• Circular wait A set of processes P0,,Pn such
  that Pi is waiting for a resource held by Pi1
  and Pn is waiting for a resource held by P0

56
Resource-Allocation Graphs

• Process
• Resource Type with 4 instances
• Pi requests instance of Rj
• Pi is holding an instance of Rj

Pi
Rj
Pi
Rj
57
Resource Allocation Graph
request edge
assignment edge
deadlocked
58
Graph With A Cycle But No Deadlock
59
Handling Deadlock

• Deadlock prevention ensure that at least one of
  the necessary conditions cannot occur
• Deadlock avoidance analysis determines whether
  a new request could lead toward a deadlock
  situation
• Deadlock detection detect and recover from any
  deadlocks that occur

60
Deadlock Prevention

• Prevent deadlocks by ensuring one of the required
  conditions cannot occur
• Mutual exclusion ? this condition typically
  cannot be removed for non-sharable resources
• Hold and wait ? elimination requires that
  processes request and acquire all resources in
  single atomic action
• No preemption ? add pre-emption when waiting for
  a resource and some other processes needs a
  resource currently held
• Circular wait ? require processes to acquire
  resources in some ordered way.

61
Deadlock Avoidance

• When a process requests an available resource,
  system must decide if immediate allocation leaves
  the system in a safe state.
• System is in safe state if there exists a
  sequence ltP1, P2, , Pngt of ALL the processes
  in the systems such that for each Pi, the
  resources that Pi can still request can be
  satisfied by currently available resources
  resources held by all the Pj, with j lt i. If a
  system is in safe state ? no deadlocks.
• If a system is in unsafe state ? possibility of
  deadlock.
• Avoidance ? ensure that a system will never enter
  an unsafe state.

62
Example Deadlock Avoidance

• Overall System has 12 tape drives and 3
  processes
• Safe state ltP1, P0, P2gt
• P1 only needs 2 of the 3 remaining drives
• P0 needs 5 (3 remaining 2 held by P1)
• P2 needs 7 (3 remaining 4 held by P0)

3 free drives
63
Example (contd)

• Overall System has 12 tape drives and 3
  processes.
• Now P2 requests 1 more drive are we still in a
  safe state if we grant this request??
• Unsafe state only P1 can be granted its request
  and once it terminates, there are still not
  enough drives for P0 and P2 ? potential deadlock
• Avoidance algorithm would make P2 wait

2 free drives
64
Avoidance algorithms

• Single instance of a resource type. Use a
  resource-allocation graph
• Multiple instances of a resource type. Use the
  bankers algorithm

65
Resource-Allocation Graph Scheme

• Claim edge Pi ? Rj indicated that process Pi may
  request resource Rj represented by a dashed
  line.
• Claim edge converts to request edge when a
  process requests a resource.
• Request edge converted to an assignment edge when
  the resource is allocated to the process.
• When a resource is released by a process,
  assignment edge reconverts to a claim edge.
• Resources must be claimed a priori in the system.

66
Resource-Allocation Graph

• P1 has been assigned R1
• P2 has requested R1
• Both P1 and P2 may request
• R2 in the future
• A request can be granted only
• if converting the request edge
• to an assignment edge does not
• result in the formation of a cycle in
• the resource allocation graph

67
Unsafe State In Resource-Allocation Graph
68
Bankers Algorithm

• Multiple instances.
• Each process must a priori claim maximum use.
• When a process requests a resource it may have to
  wait.
• When a process gets all its resources it must
  return them in a finite amount of time.

69
Bankers Algorithm

• Overall System has m3 different resource types
  (A10, B5, C7) and n5 processes
• In a safe state??

70
Data Structures for the Bankers Algorithm
Let n number of processes, and m number of
resources types.

• Available Vector of length m. If available j
  k, there are k instances of resource type Rj
  available.
• Max n x m matrix. If Max i,j k, then
  process Pi may request at most k instances of
  resource type Rj.
• Allocation n x m matrix. If Allocationi,j
  k then Pi is currently allocated k instances of
  Rj.
• Need n x m matrix. If Needi,j k, then Pi
  may need k more instances of Rj to complete its
  task.
• Need i,j Maxi,j Allocation i,j.

71
Bankers Algorithm (contd)

• Overall System has 3 different resource types
  (A10, B5, C7) and 5 processes
• safe state ltP1,P3,P4,P2,P0gt

72
Bankers Algorithm (contd)

• ltP1,P3,P4,P2,P0gt
• All of P1s requests can be granted from
  available

73
Bankers Algorithm (contd)

• ltP1,P3,P4,P2,P0gt
• Once P1 ends, P3s requests could be granted

74
Bankers Algorithm (contd)

• ltP1,P3,P4,P2,P0gt
• Once P3 ends, P4s requests could be granted

75
Bankers Algorithm (contd)

• ltP1,P3,P4,P2,P0gt
• Once P4 ends, P2s requests could be granted

76
Bankers Algorithm (contd)

• ltP1,P3,P4,P2,P0gt
• Once P2 ends, P0s requests could be granted

77
Safety Algorithm (Sec. 7.5.3.1)

• 1. Let Work and Finish be vectors of length m and
  n, respectively. Initialize
• Work Available
• Finish i false for i 0, 1, , n- 1.
• 2. Find an i such that both
• (a) Finish i false
• (b) Needi ? Work
• If no such i exists, go to step 4.
• 3. Work Work AllocationiFinishi truego
  to step 2.
• 4. If Finish i true for all i, then the
  system is in a safe state.

May require m x n2 operations
78
Bankers Algorithm (contd)

• Starting from previous state, suppose P1 requests
  (1,0,2). Should this be granted?
• ltP1gt

3
2
0
0

2
0
79
Bankers Algorithm (contd)

• P1 requests (1,0,2). Should this be granted?
• ltP1,P3gt

80
Bankers Algorithm (contd)

• P1 requests (1,0,2). Should this be granted?
• ltP1,P3,P0gt

81
Bankers Algorithm (contd)

• P1 requests (1,0,2). Should this be granted?
• ltP1,P3,P0,P2gt

82
Bankers Algorithm (contd)

• P1 requests (1,0,2). Should this be granted?
• ltP1,P3,P0,P2,P4gt

83
Bankers Algorithm (contd)

• Now, P4 requests (3,3,0). Should this be
  granted?
• No more than the available resources

84
Bankers Algorithm (contd)

• Now, P0 requests (0,2,0). Should this be
  granted?

85
Resource-Request Algorithm for Process Pi (Sec
7.5.3.2)

• Request request vector for process Pi.
  If Requesti j k then process Pi wants k
  instances of resource type Rj.
• 1. If Requesti ? Needi go to step 2. Otherwise,
  raise error condition, since process has exceeded
  its maximum claim.
• 2. If Requesti ? Available, go to step 3.
  Otherwise Pi must wait, since resources are not
  available.
• 3. Pretend to allocate requested resources to Pi
  by modifying the state as follows
• Available Available Request
• Allocationi Allocationi Requesti
• Needi Needi Requesti
• If safe ? the resources are allocated to Pi.
• If unsafe ? Pi must wait, and the old
  resource-allocation state is restored

86
Deadlock Detection and Recovery

• Allow system to enter deadlock state
• Detection algorithm
• Single Instance (look for cycles in wait-for
  graph)
• Multiple instance (related to bankers algorithm)
  Algorithm requires an order of O(m x n2)
  operations to detect whether the system is in
  deadlocked state.
• Recovery scheme

87
Resource-Allocation Graph and Wait-for Graph
Resource-Allocation Graph
Corresponding wait-for graph
88
Detection-Algorithm Usage

• When, and how often, to invoke depends on
• How often a deadlock is likely to occur?
• How many processes will need to be rolled back?
• one for each disjoint cycle
• If detection algorithm is invoked arbitrarily,
  there may be many cycles in the resource graph
  and so we would not be able to tell which of the
  many deadlocked processes caused the deadlock.

89
Recovery from Deadlock Process Termination

• Abort all deadlocked processes.
• Abort one process at a time until the deadlock
  cycle is eliminated.
• In which order should we choose to abort?
• Priority of the process.
• How long process has computed, and how much
  longer to completion.
• Resources the process has used.
• Resources process needs to complete.
• How many processes will need to be terminated.
• Is process interactive or batch?

90
Recovery from Deadlock Resource Preemption

• Selecting a victim minimize cost.
• Rollback return to some safe state, restart
  process for that state.
• Starvation same process may always be picked
  as victim, include number of rollbacks in cost
  factor.