Concurrency: Deadlock and Starvation

1
Concurrency Deadlock and Starvation

• Chapter 6

2
Deadlock

• Permanent blocking of a set of processes that
  either compete for system resources or
  communicate with each other
• There is no satisfactory solution in the general
  case
• Most general purpose OSs (ex Unix SVR4) ignore
  the problem and pretend that deadlocks never occur

3
(No Transcript)
4
Deadlock and Resources

• Reusable resources
• serially shareable used by one process at a time
• examples include devices (disk, tape drives)
  memory, and files (unless in read-only mode)
• a system generally has a fixed number or amount
  of each type of reusable resource
• such resources allocated in units two tape
  drives, 4K of memory, etc.

5
Deadlock Reusable Resources

• Process P
• request disk
• request tape
• perform function
• release disk
• release tape

• Process Q
• request tape
• request disk
• perform function
• release tape
• release disk

If Process P is allowed to lock the disk, and
Process Q locks the tape, P and Q will become
deadlocked. Each is in the Blocked state,
waiting for a resource that belongs to another
blocked process.
6
Another Example of Deadlock

• Space is available for allocation of 200Kbytes,
  and the following sequence of events occur
• Deadlock occurs if both processes progress to
  their second request

P1
P2
. . .
. . .
Request 80 Kbytes
Request 70 Kbytes
. . .
. . .
Request 60 Kbytes
Request 80 Kbytes
7
Deadlock and Resources

• Consumable resources
• produced and consumed in real time
• each instance of the resource is used only once
• examples messages, signals, interrupts
• usually used in process synchronization
• Most deadlock theory assumes reusable resources.

8
Deadlock on Consumable Resources( messages are
the resource consumed)
P1 Receive (P2) Send (P2)
P2 Receive (P1) Send (P1)
If receives are blocking, this approach will
result in a deadlock.
9
Resource Allocation Graphs

• Directed graph that depicts current state of
  system resources and processes
• Can be used to detect deadlock.
• Dots in resource node represent number of units
  of the resource that exist.

10
Resource Allocation Graphs
11
Conditions for Deadlock

• There are three policy conditions that must be
  present for deadlock to be possible
• mutual exclusion only one process may use a
  resource at a time
• hold and wait (incremental allocation) a process
  may hold allocated resources while waiting for
  others
• no preemption no resource can be forcibly
  removed from a process holding it

12
Conditions for Deadlock

• In addition to the 3 policy conditions, there is
  a fourth condition which must be present if
  deadlock is to occur 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

13
Conditions for Deadlock

• In summary, there are FOUR necessary and
  sufficient conditions to ensure deadlock.
• Three policy conditions make deadlock possible -
  if any one of the three does not hold, there can
  never be deadlock.
• The fourth condition is a condition of
  circumstance a particular sequence of events
  leads to the circular wait.

14
Approaches to Deadlock Management

• Prevention disallow one of the four necessary
  conditions for deadlock.
• Avoidance do not grant a resource request if
  this allocation might lead to deadlock (notice
  that prevention and avoidance both keep deadlock
  from happening).
• Detectiongrant resource request when possible.
  But periodically check for deadlock and then
  recover from it.

15
Deadlock Prevention

• Deadlock prevention methods
• Design the OS so deadlock is not possible.
• Two approaches
• Disallow one of the first three conditions i.e.,
  do not implement one of these policies.
• Prevent resource requests which might lead to
  circular wait

16
Deadlock Prevention

• Do not allow mutual exclusion
• Not a good idea - mutual exclusion is essential
• Prevent hold-and-wait
• Force processes to request all resources at once
• Process is blocked until all resources can be
  granted
• Disadvantages
• Processes might have to wait for a long time
• Resources may remain unused for a long time
• Applications must know in advance which resources
  will be needed

17
Deadlock Prevention

• Allow resource preemption
• Require a process to give up all current
  resources if it needs to wait for another
  resource. It can then wait for all needed
  resources.
• Allow high priority processes to preempt
  resources from low priority processes.
• In either case, resource state must be saved for
  the process whose resource is confiscated.
• This limits applicability of technique. Can only
  be used for resources whose state can be easily
  saved - CPU, for example, or memory.

18
Deadlock Prevention - Forbid Circular Wait

• Prevent the circular wait.
• Define a linear order for all resource types R0,
  R1, R2, ...
• If a process has already acquired resource type
  Ri, it is allowed to request Rj only if i lt j.
• This approach would solve the tape drive/disk
  drive deadlock example

19
Deadlock Prevention - Forbid Circular Wait

• To prove resource numbering works, assume the
  contrary.
• Suppose A and B are deadlocked. A owns Ri and is
  waiting for Rj this implies that i lt j.
• B owns Rj and is waiting for Ri. This implies
  that j lt i, which is a contradiction.
• Thus, there can be no deadlock with resource
  numbering - proof by contradiction.

20
Deadlock Prevention Summary

• Deny mutual exclusion is impossible.
• Deny hold-and-wait or prevent circular wait is
  inefficient processes may have to acquire
  resources before they need them, which means
  other processes are denied the resources.
• Permit preemption - at best, of limited use.

21
Deadlock Avoidance

• Permit the three policies (mutual exclusion,
  hold-and-wait, no preemption) but allocate
  resources so no circular wait can happen.
• Two methods
• Process initiation denial
• Resource allocation denial
• In each method maximum resources requirements
  must be stated in advance

22
Process Initiation Denial

• Assume the system has n processes and m resource
  types.
• Each of the n processes has claimed a certain
  amount of resources.
• We will refuse to start process P(n1) if its
  resource needs exceed the total of unclaimed
  system resources.

23
Process Initiation Denial

• For each resource type let R(i) represent the
  total amount of resource i in the system.
• V(i) represents the amount of R(i) not already
  promised to a running process.
• C(k,i) represents the amount of R(i) that process
  P(k) will claim.
• P(k) can start if and only if C(k,i) lt V(i).

24
Process Initiation Denial

• Example
• R(1) (main memory) 128 MB
• R(2) (disk drives) 8
• Currently, (Vi is unpromised units of Ri)
• V(1) 64MB, V(2) 2
• If P(k) needs 32MB and 3 disk drives, it will not
  be allowed to start.

25
Resource Allocation Denial The Bankers Algorithm

• Process initiation denial is clearly not an
  optimal strategy.
• Wont let a process start unless there are enough
  resources in the system to satisfy the maximum
  claims of all processes at the same time.
• The Bankers Algorithm is less conservative
  processes are initiated, but may block later if
  they cant get resources.

26
Bankers Algorithm - Definitions

• System state is defined by the Resource vector
  R(i), the Claim matrix C(j,i), the Available
  vector V(i) and the Allocation matrix A(j,i)
  (amount of resource i allocated to process j).
  Just as in previous method.
• Also, Need matrix N(j,i) gives amount of resource
  type i required by process j to complete its task

27
Bankers Algorithm

• Some relations between state values
• V(i) R(i) - S_k A(k,i)
• N(j,i) C(j,i) - A(j,i)
• In all cases, we assume that each process will
  eventually need its maximum request. This isnt
  necessarily true, but to be safe we must do so.

28
Bankers Algorithm

• To decide if a processs resource request should
  be granted, check to see if granting the request
  will lead to a safe state.
• if resulting state is safe, grant request
• otherwise deny request and block the process
• This may mean that a process is blocked on a
  resource request even if some amount of the
  resource is available.

29
Bankers Algorithm

• A state is safe iff there exists some sequence of
  resource allocationsP1..Pn in which each
  process Pi is allocated all the resources it
  needs to be run to completion
• In other words, all processes can run to
  completion from a safe state.
• Unsafe state one that isnt safe (not
  necessarily one that will lead to deadlock)

30
Example

• Suppose there are 6 disk drives available P1
  needs 3 and P2 needs 5 i.e., C1 3 and C2 5.
• Also suppose P1 has been granted 2, P1 has been
  granted 3.
• This is a safe state P1 can finish first and
  then P2.
• If P1 had 2 and P2 had 4 the state would be
  unsafe.

31
Bankers AlgorithmTest for Safe State

• The Safety Algorithm (Figure 6.8) formalizes the
  process of finding a safe-state sequence.
• Here are some examples

32
Bankers Algorithm Example

• Resource vector is R(1)9, R(2)3, R(3)6
• n 4 (there are 4 processes)
• The current state

Claimed Allocated
Available
R1 R2 R3
R1 R2 R3
R1 R2 R3
3 2 2 6 1 3 3 1 4 4 2
2
1 0 0 5 1 1 2 1 1 0 0
2
1 1 2
P1 P2 P3 P4

• Suppose that P2 requests (1,0,1). Should this
  request be granted?

33
Example (continued)

• If request is granted, the state would be

Claimed Allocated
Available
R1 R2 R3
R1 R2 R3
R1 R2 R3
3 2 2 6 1 3 3 1 4 4 2
2
1 0 0 6 1 2 2 1 1 0 0
2
0 1 1
P1 P2 P3 P4

• This state is safe with sequence P2, P1, P3,
  P4. After P2 finishes, the Available vector is
  (6,2,3) which enables the other processes to
  finish. Hence request granted.

34
Example - Unsafe State

• If, however, P1 requested (1,0,1) the resulting
  state would be

Claimed Allocated
Available
R1 R2 R3
R1 R2 R3
R1 R2 R3
3 2 2 6 1 3 3 1 4 4 2
2
2 0 1 5 1 1 2 1 1 0 0
2
0 1 1
P1 P2 P3 P4

• This is not a safe state. Every process needs one
  additional unit of R1 but none is left.
• Request refused P1 is blocked.

35
Deadlock AvoidanceSummary

• Both forms of avoidance have drawbacks
• The maximum requirement for each process must be
  known and stated in advance
• The system must have a fixed number of resources
  to allocate.
• Processes must be independent - the system must
  be able to determine their execution order.
• Processes must relinquish all resources when they
  exit.

36
Third Approach to Deadlock Detection

• Detection and recovery techniques dont restrict
  resource allocation - a reasonable approach in
  environments where deadlock is rare.
• Also provides more concurrency since processes
  arent denied or blocked because of possible
  deadlocks.

37
Deadlock Detection

• Resource accesses 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
• Frequent checks consume CPU time, so the check
  may be done periodically instead.

38
Detection Algorithms

• Several algorithms exist
• Some are based on resource allocation graphs,
  which indicate resource ownership and pending
  requests. A deadlock is equivalent to a cycle in
  the graph
• Another algorithm uses the Allocation matrix and
  the Available vector, plus a request matrix Q,
  where qij represents the pending request for Rj
  by process i. (See description on page 272)

39
Recovery Algorithms

• When deadlock is discovered, there must be some
  mechanism for recovery, such as
• abort all or some of the deadlocked processes
• preempt resources until no deadlock exists
• rollback/restart, which requires taking periodic
  checkpoints of each process. Transaction
  processing systems use this approach.
• Priorities establish order of abort, preempt
  operations.

40
Strengths and Weaknesses of the Strategies
41
Integrated Deadlock Strategy

• Prevention and avoidance strategies are
  time-consuming and limit concurrency - too
  inefficient for most systems to use.
• On the other hand, detection and recovery risks
  lost work and unrecoverable errors.
• Suggest an integrated strategy group resources
  into categories, use a different approach for
  each category.

42
Integrated Deadlock Strategy

• Use linear ordering between resource classes (if
  you already have a resource from class 2, cant
  request any more from class 1)
• Within a resource class, use either prevention,
  avoidance, or detection.
• For example, if the resource is main memory, use
  prevention through preemption.

43
The Dining Philosphers

• Yet another synchronization problem - this one
  models resource allocation and deadlock.

44
The Dining Philosophers Problem

• 5 philosophers sit at a round table with 5 forks
  and a bowl of food.
• Philosophers think, pick up forks, eat, put down
  forks.
• Eating requires two forks, a fork can be used by
  only one philosopher at a time.

45
Dining Philosophers Problem
46
Dining Philosophers Problem
47
Semaphore Solution

• This solution may lead to deadlock. Its possible
  for each philosopher to pick up the left fork
  first, and then no philosopher can get the right
  fork.
• The next solution only permits 4 philosophers in
  the dining room at a time. Now at least one will
  be able to get both forks no deadlock.

48
Dining Philosophers Problem
49
Next Lecture

• Readers and Writers Problem (Chapter 5)
• Concurrency mechanisms in real world operating
  systems 6.7, 6.8, 6.9, 6.10.