Chapter 6 Concurrency: Deadlock and Starvation

1
Chapter 6Concurrency Deadlock and Starvation
2
Deadlock

• Permanent blocking of a set of processes that
  either compete for system resources or
  communicate with each other
• Involves conflicting needs for resources by two
  or more processes
• There is no satisfactory solution in the general
  case

3
Example where deadlock can occur
4
Example where deadlock cannot occur
5
The Conditions for Deadlock

• These 3 conditions of policy must be present for
  a deadlock to be possible
• 1 Mutual exclusion
• only one process may use a resource at a time
• 2 Hold-and-wait
• a process may hold allocated resources while
  awaiting assignment of others
• 3 No preemption
• no resource can be forcibly removed from a
  process holding it

6
The Conditions for Deadlock

• We also need the occurrence of a particular
  sequence of events that result in
• 4 Circular wait
• a closed chain of processes exists, such that
  each process holds at least one resource needed
  by the next process in the chain

7
The Conditions for Deadlock

• The first 3 conditions are necessary, but not
  sufficient
• Deadlock occurs if and only if the circular wait
  condition is unresolvable.
• The circular wait condition is unresolvable when
  the first 3 policy conditions hold
• Thus the 4 conditions taken together constitute
  necessary and sufficient conditions for deadlock

8
Methods for handling deadlocks

• Deadlock prevention
• disallow 1 of the 4 conditions of deadlock
  occurrence
• Deadlock avoidance
• do not grant a resource request if this
  allocation might lead to deadlock
• Deadlock detection
• always grant resource request when possible. But
  periodically check for the presence of deadlock
  and then recover from it

9
Deadlock Prevention

• The OS is design in such a way as to exclude a
  priori the possibility of deadlock
• Indirect methods of deadlock prevention
• to disallow one of the 3 policy conditions
• Direct methods of deadlock prevention
• to prevent the occurrence of circular wait

10
Indirect methods of deadlock prevention

• Mutual Exclusion
• cannot be disallowed
• ex only 1 process at a time can print to a
  printer

11
Indirect methods of deadlock prevention

• Hold-and-Wait
• can be disallowed by requiring that a process
  request all its required resources at one time
• block the process until all requests can be
  granted simultaneously
• A process may be held up for a long time waiting
  for all its requests
• an application would need to be aware of all the
  resources that will be needed

12
Indirect methods of deadlock prevention

• No preemption
• Can be prevented in several ways
• Process making a resource request must release
  its original resources if the request is denied
• If the requested resource is held by another
  process, it may be preempted to release it
• But whenever a process must release a resource
  whose usage is in progress, the state of this
  resource must be saved for later resumption.
• Hence practical only when the state of a
  resource can be easily saved and restored later,
  such as the processor.

13
Direct methods of deadlock prevention

• A protocol to prevent circular wait
• define a strictly increasing linear ordering O()
  for resource types. Ex
• R1 tape drives O(R1) 2
• R2 disk drives O(R2) 4
• R3 printers O(R3) 7
• Assume a process has been allocated resources of
  type Ri
• After that, the process can request resources of
  type Rj if and only if O(Rj) gt O(Ri)

14
Prevention of circular wait

• Circular wait cannot hold under this protocol.
• Proof suppose processes P1 and P2 are deadlocked
  because
• P1 has control of Ri and requested Rj and
• P2 has control of Rj and requested Ri
• This is impossible because it implies O(Ri) lt
  O(Rj) and O(Rj) lt O(Ri)
• Inefficient may deny resources unnecessarily
  because of ordering imposed on requests

15
Deadlock Prevention Summary

• We disallow one of the 3 policy conditions or use
  a protocol that prevents circular wait
• This leads to inefficient use of resources and
  slowing down of processes

16
Deadlock Avoidance

• We allow the 3 policy conditions but make
  judicious choices to assure that the deadlock
  point is never reached
• Allows more concurrency than prevention
• Two approaches
• do not start a process if its demand might lead
  to deadlock
• do not grant an incremental resource request if
  this allocation might lead to deadlock
• In both cases maximum requirements of each
  resource must be stated in advance

17
Resource types

• Resources in a system are partitioned into
  resources types
• Each resource type in a system exists with a
  certain amount. Let R(i) be the total amount of
  resource type i present in the system. Ex
• R(main memory) 128 MB
• R(disk drives) 8
• R(printers) 5
• The partition is system specific (ex printers
  may be further partitioned...)

18
Process initiation denial

• Let C(k,i) be the amount of resource type i
  claimed by process k.
• C(k,i) is the maximum value of resource type i
  permitted for process k.
• Let U(i) be the total amount of resource type i
  unclaimed in the system running n processes
• U(i) R(i) SUMC(1n,i)
• New process is not started if its resource
  requirements might lead to deadlock
• New process started only if
• U(i) gt C(n1,i) for all i
• Far from optimal because it assumes the worst
  all processes make their maximum claims together

19
Resource Allocation Denial

• Referred to as the bankers algorithm
• State of the system is the current allocation of
  resources to process
• Safe state is where there is at least one
  sequence that does not result in deadlock
• Unsafe state is a state that is not safe

20
Determination of a Safe StateInitial State
21
Determination of a Safe StateP2 Runs to
Completion
22
Determination of a Safe StateP1 Runs to
Completion
23
Determination of a Safe StateP3 Runs to
Completion
24
Determination of an Unsafe State

• If P2 requests one additional unit of R1 and one
  unit of R3 the resulting state is safe (already
  discussed)

25
Determination of an Unsafe State

• This state is unsafe because each process needs
  at least one unit of R1
• To avoid deadlock, request by P1 should be denied
  and P1 should be blocked

26
Unsafe State

• Unsafe state is NOT a deadlock state. It merely
  has the potential for deadlock
• Ex if P1 releases one unit of R1 and one unit of
  R3 when run, the system would return to a safe
  state.
• Deadlock avoidance strategy merely predicts the
  possibility of deadlock and assures that there is
  never such a possibility

27
Deadlock Avoidance

• Restrictions on use
• Maximum resource requirement must be stated in
  advance
• Processes under consideration must be
  independent no synchronization requirements
  constrain order of execution
• There must be a fixed number of resources to
  allocate
• No process may exit while holding resources
• Advantage less restrictive than deadlock
  prevention not necessary to preempt and roll
  back processes as in deadlock detection.

28
Deadlock Detection

• Resource access are granted to processes whenever
  possible. The OS needs
• an algorithm to check if deadlock is present
• an algorithm to recover from deadlock
• The deadlock check can be performed at every
  resource request
• Such frequent checks consume CPU time

29
A deadlock detection algorithm

• Makes use of the following resource-allocation
  matrices and vectors
• Allocation matrix A(j,i)
• Number of units of resource type i allocated to
  process j
• Available vector V(i)
• Number of units of resource type i available
• Request matrix Q(j,i)
• Number of units of resource type i requested by
  process j
• Temporary work vector W(i)

30
A deadlock detection algorithm

• Marks each process not deadlocked. Initially all
  processes are unmarked. Then perform
• Mark each process j for which A(j,i) 0 for all
  resource type i. (since these are not deadlocked)
• Initialize work vector W(i) V(i) for all i
• REPEAT Find a unmarked process j such that
  Q(j,i) lt W(i) for all i. Stop if such j does not
  exists.
• If such j exists mark process j and set W(i)
  W(i) A(j,i) for all i. Goto REPEAT
• At the end each unmarked process is deadlocked

31
Deadlock detection comments

• Process j is not deadlocked when Q(j,i) lt W(i)
  for all i.
• Then we are optimistic and assume that process j
  will require no more resources to complete its
  task
• It will thus soon return all of its allocated
  resources. Thus W(i) W(i) A(j,i) for all i
• If this assumption is incorrect, a deadlock may
  occur later
• This deadlock will be detected the next time the
  deadlock detection algorithm is invoked

32
Deadlock detection example
Request Allocated
Available
R1 R2 R3 R4 R5
R1 R2 R3 R4 R5
R1 R2 R3 R4 R5
P1 P2 P3 P4
0 1 0 0 1 0 0 1 0
1 0 0 0 0 1 1 0 1 0
1
1 0 1 1 0 1 1 0 0
0 0 0 0 1 0 0 0 0 0
0
0 0 0 0 1

• Mark P4 since it has no allocated resources
• Set W (0,0,0,0,1)
• P3s request lt W. So mark P3 and set W W
  (0,0,0,1,0) (0,0,0,1,1)
• Algorithm terminates. P1 and P2 are deadlocked

33
Deadlock Recovery

• Needed when deadlock is detected. The following
  approaches are possible
• Abort all deadlocked processes (one of the most
  common solution adopted in OS!!)
• Rollback each deadlocked process to some
  previously defined checkpoint and restart them
  (original deadlock may reoccur)
• Successively abort deadlocked processes until
  deadlock no longer exists (each time we need to
  invoke the deadlock detection algorithm)

34
Deadlock Recovery (cont.)

• Successively preempt some resources from
  processes and give them to other processes until
  deadlock no longer exists
• a process that has a resource preempted must be
  rolled back prior to its acquisition
• Reinvocation of detection algorithm required.
• For the 2 last approaches a victim process needs
  to be selected according to one of the following
• least amount of CPU time consumed so far
• least total resources allocated so far
• least amount of work produced so far
• Lowest priority, etc.

35
An integrated deadlock strategy

• Table 6.1, page 272.
• Each deadlock strategy has its strengths and
  weaknesses
• Using a single strategy may be inefficient
• We can combine the previous approaches into the
  following way
• Group resources into a number of different
  classes and order them. Ex
• Swappable space (secondary memory)
• Process resources (I/O devices, files...)
• Main memory, etc.

36
An integrated deadlock strategy

• (contd)
• Use prevention of circular wait strategy to
  prevent deadlock between resource classes
• Use the most appropriate approach for deadlocks
  within each class
• Swappable space hold-and-wait prevention,
  deadlock avoidance
• Process resources avoidance, prevention by
  resource ordering
• Main memory prevention by preemption

37
The Dining Philosophers Problem

• 5 philosophers who only eat and think
• each need to use 2 forks on either side for
  eating
• we have only 5 forks
• Enforce mutual exclusion on each fork
• Avoid deadlock and starvation

• A classical synchronization problem
• Illustrates the difficulty of allocating
  resources among process without deadlock and
  starvation

38
The Dining Philosophers Problem

• Each philosopher is a process
• One semaphore per fork
• fork array0..4 of semaphores
• Initialization forki.count1 for i0..4
• A first attempt
• Deadlock if each philosopher start by picking his
  left fork!

Process Pi repeat think wait(forki)
wait(forki1 mod 5) eat signal(forki1 mod
5) signal(forki) forever
39
The Dining Philosophers Problem

• A solution admit only 4 philosophers at a time
  who try to eat
• Then 1 philosopher can always eat when the other
  3 are holding 1 fork
• Hence, we can use another semaphore T that would
  limit at 4 the num. of philosophers sitting at
  the table
• Initialize T.count4

Process Pi repeat think wait(T)
wait(forki) wait(forki1 mod 5) eat
signal(forki1 mod 5) signal(forki)
signal(T) forever