Concurrency: Deadlock and Starvation

1
Concurrency Deadlock and Starvation

• Chapter 6

2
Objectives

• know what deadlock is
• be able to describe the four necessary and
  sufficient conditions for deadlock to occur
• be familiar with deadlock prevention, avoidance,
  and detection/recovery mechanisms

3
Deadlock

• Permanent blocking of a set of processes that
  either compete for system resources or
  communicate with each other
• No efficient solution
• Involve conflicting needs for resources by two or
  more processes
• determine whether a program contains a potential
  deadlock is a computationally unsolvable problem

4
(No Transcript)
5
Not Joking
6
(No Transcript)
7
(No Transcript)
8
Reusable Resources

• Used by one process at a time and not depleted
  (used up) by that use
• Processes obtain resources that they later
  release for reuse by other processes
• Processors, I/O channels, main and secondary
  memory, files, databases, and semaphores
• Deadlock occurs if each process holds one
  resource and requests the other

9
Example of Deadlock
10
Another Example of Deadlock

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

P1
P2
. . .
. . .
Request 80K bytes
Request 70K bytes
. . .
. . .
Request 60K bytes
Request 80K bytes
11
Consumable Resources

• Created (produced) and destroyed (consumed) by a
  process
• Interrupts, signals, messages, and information in
  I/O buffers
• Deadlock may occur if Receive message is a
  blocking call
• May take a rare combination of events to cause
  deadlock

12
Example of Deadlock

• Deadlock occurs if receive is blocking

P1
P2
. . .
. . .
Receive(P2)
Receive(P1)
. . .
. . .
Send(P2, M1)
Send(P1, M2)
13
Conditions for Deadlock

• These 3 conditions must be present for a deadlock
  to be possible (necessary conditions)
• Mutual exclusion
• Only one process may use a resource at a time
• Hold-and-wait
• A process holds one resource while requesting
  another resource
• No Preemption
• No resource may be removed from a process by force

14
Conditions for Deadlock

• Circular wait
• A closed chain of processes exists such that each
  process holds resource needed by next

15
All Conditions

• First three conditions lead to the fourth
  condition
• All four conditions are necessary and sufficient
  for a deadlock to occur
• All four of these 4 conditions must be present
  for a deadlock to occur. If one of them is
  absent, no deadlock is possible.
• Design the system to exclude the possibility of a
  deadlock!!

16
More on circular wait

• Circular wait does not imply deadlock if one of
  the processes in the loop can obtain the resource
  in another way

17
Methods for Handling Deadlocks

• Ensure that the system will never enter a
  deadlock state
• Deadlock Prevention. Constrain resource requests
  to prevent at least one of the four conditions of
  deadlock
• Deadlock Avoidance. Allow the three necessary
  conditions, but make judicious choices to assure
  that the deadlock point can never be reached
• Allow the system to enter a deadlock state and
  then recover
• Ignore the problem and pretend that deadlocks
  never occur in the system (the ostrich strategy)
• used by most operating systems, including UNIX

18
Deadlock Prevention

• Constrain resource requests to prevent at least
  one of the four conditions of deadlock
• Mutual Exclusion cannot be banned!
• Hold-and-Wait
• Preventing it requires that each process requests
  all its required resources at one time and gets
  blocked until all requests can be granted
  simultaneously
• Problems
• process may be held up for a long time waiting
  for all its requests
• resources allocated to a process may remain
  unused for a long time. These resources could be
  used by other processes
• an application would need to be aware of all the
  resources that will be needed

19
Deadlock Prevention (ctd.)

• No preemption
• (1)To prevent deadlock, the following rule should
  apply if a process is denied a further request,
  the process must release the resources that it
  already has (2) or ask the other process who
  hold requested resource to meet the demand of the
  requesting process
• The OS must be able to restore the state that the
  process had before releasing the resources.
  Therefore, this method is only practical when the
  state can be easily saved and resources restored
  later (e.g., releasing the processor)

20
Deadlock Prevention (ctd.)

• Circular wait
• define a linear ordering for resources
• once a resource is obtained, only those resources
  higher in the list can be obtained
• may deny resources unnecessarily
• (prevention strategies are not practical)
• A
• B ltltlt process2 (2) allow A only
• C
• D ltltlt process1 (1) allow A, B, C only
• E ltltlt process3

21
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
  inefficient execution of processes

22
Resource-Allocation Graph

• A set of vertices V and a set of edges E.
• V is partitioned into two types
• P P1, P2, ..., Pn, the set consisting of all
  the processes in the system.
• R R1, R2, ..., Rm, the set consisting of all
  resource types in the system.
• Request edge directed edge Pi -gt Rj
• Assignment edge directed edge Rj -gt Pi

23
Legend of the Resource-Allocation Graph

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

24
Example of a Graph With No Cycles
If graph contains no cycles ? no
deadlock.
25
Example of a Graph With Cycles

• If graph contains a cycle
• ?
• if only one instance
• per resource type,
• then deadlock.
• if several instances
• per resource type,
• possibility of deadlock.
• must ask question is there a process that can
  terminate and if so, which other processes can
  terminate as a consequence?

26
Resource allocation graph with deadlock
Cycles P1 ? R1 ? P2 ? R3 ? P3 ? R2 ? P1 P2 ? R3
? P3 ? R2 ? P2 cannot get out
27
Deadlock Avoidance

• Prevention results in inefficient use of
  resources
• We can use deadlock avoidance in which first
  three conditions still hold
• A decision is made dynamically whether the
  current resource allocation request will, if
  granted, potentially lead to a deadlock
• Requires knowledge of future process request

28
Two Approaches to Deadlock Avoidance

• Do not start a process if its demands might lead
  to deadlock
• Do not grant an incremental resource request to a
  process if this allocation might lead to deadlock

29
Useful Data Structures
Let n number of processes, and m number of
resources types.

• Resource vector of length m. If Resourcej k,
  there are totally k instances of resource type Rj
  
• Available vector of length m. If Available j
  k, there are k instances of resource type Rj
  available now
• Claim n ? m matrix. If Claimi,j k, then
  process Pi may request at most k instances of
  resource type Rj.
• Allocation n ? m matrix. If Allocationi,j
  k then Pi is currently allocated k instances of
  Rj.

30
Process Initiation Denial

• Refuse to start a new process if its resource
• requirements might lead to deadlock
• In other words, start a new process Pn1 only
  if
• Ri ? Claimn1, i ?1?k?n Claimk, i ?i
• i.e. the maximum claim of all current
  processes plus those of the new process can be
  met.

• It is a worst case strategy because it assumes
  the worst (all required resources will be needed
  at the same time) so it is an inefficient approach

31
Resource Allocation Denial

• Referred to as the bankers algorithm (Dijkstra
  1965)
• System is in safe state if there exists a safe
  sequence of all processes.
• Sequence lt P1, P2, ..., Pngt is safe if for each
  Pi, the resources that Pi can still request can
  be satisfied by currently available resources
  resources held by all the Pj, with jlti.
• If Pi resource needs are not immediately
  available,
• then Pi can wait until all Pj have finished
• When Pj is finished, Pi can obtain needed
  resources,
• execute, return allocated resources, and
  terminate
• When Pi terminates, Pi1 can obtain its needed
• resources, and so on.

Avoidance ensure that a system will never enter
an unsafe state.
32
Determination of a Safe State
P4
33
Example of an Unsafe State
SAFE
UNSAFE
34
Bankers Algorithm
struct state int resourcem int
availablem int claimnm int
allocationnm
boolean safe(state s) int currentavailm
process restltnumber of processesgt
currentavail available rest all
processes possible true while
(possible) find a Pk ?rest such that
claimk, allocationk, ?
currentavail if (found)
/ simulate execution of Pk,
and then collect the released resources /
currentavail allocationk,
rest - Pk else
possible false return
(rest null) Test for safety Algorithm

if (allocationi, request gt claimi, )
/ error since total request gt claim /
elseif (request gt available) /
suspend process because no enough
resource / else / simulate allocation
/ / define newstate by
allocationi, request
available - request / if
(safe(newstate)) / carry out allocation
/ else / restore original state
suspend process / Resource Allocation
Algorithm
35
Deadlock Avoidance

• Maximum resource requirement must be stated in
  advance
• Processes under consideration must be
  independent no synchronization requirements
• There must be a fixed number of resources to
  allocate
• No process may exit while holding resources

36
Deadlock Detection

• OS does not prevent deadlocks.
• OS grants resources whenever possible.
• Detection of deadlock is not obvious
• if the OS sees some processes that wait, it
  cannot conclude that there is deadlock
• OS checks for deadlock by checking for circular
  waiting by either method
• Checking at resource request
• early detection of deadlock
• frequent checks consume processor time
• Checking periodically
• There is recovery from deadlock

37
Single Instance of Each Resource Type

• Maintain wait-for graph from the
  Resource-Allocation Graph
• Nodes are processes.
• Pi ? Pj if Pi is waiting for Pj.
• Periodically invoke an algorithm that searches
  for a cycle in the graph.
• An algorithm to detect a cycle in a graph
  requires an order of n2 operations, where n is
  the number of vertices in the graph.

38
Resource-Allocation Graph and Wait-for Graph
Resource-Allocation Graph
Corresponding wait-for graph
39
Several Instances of a Resource Type

• Available A vector of length m indicates the
  number of available resources of each type.
• Allocation An n ? m matrix defines the number
  of resources of each type currently allocated to
  each process.
• Request An n ? m matrix indicates the current
  request of each process. If Request i, j k,
  then process Pi is requesting k more instances of
  resource type Rj.

40
Detection Algorithm

• 1. Let Work and Finish be vectors of length m and
  n, respectively Initialize
• (a) Work Available
• (b) For i 1,2, , n, if Allocationi, ? 0,
  then Finishi falseotherwise, Finishi
  true.
• 2. Find an index i such that both
• (a) Finishi false
• (b) Request i, ? Work
• If no such i exists, go to step 4.

41
Detection Algorithm (Cont.)

• 3. Work Allocation i, Finishi
  truego to step 2.
• 4. If Finishi false, for some i, 1 ? i ?
  n, then the system is in deadlock state.
  Moreover, if Finishi false, then Pi is
  deadlocked.

Algorithm requires an order of O(m ? n2)
operations to detect whether the system is in
deadlocked state.
42
Example of Detection Algorithm
DEADLOCK
1
43
Note to Detection-Algorithm

• 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?
• 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.

44
Deadlock Recovery after deadlock has been
detected

• Abort all deadlocked processes
• one of the most common solution adopted in OS!!
• Back up each deadlocked process to some
  previously defined checkpoint, and restart all
  process
• original deadlock may occur
• Successively abort deadlocked processes until
  deadlock no longer exists
• each time we need to invoke the deadlock
  detection algorithm
• Successively preempt resources until deadlock no
  longer exists
• a process that has a resource preempted must be
  rolled back prior to its acquisition

45
Selection Criteria for Deadlocked Processes(34)

• Least amount of processor time consumed so far
• Least number of lines of output produced so far
• Most estimated time remaining
• Least total resources allocated so far
• Lowest priority
• Starvation same process might (but not
  definite) always be picked as victim, include
  number of rollback in cost factor.

46
(No Transcript)
47
Dining Philosophers (Dijkstra)

• Five philosophers are in deep thought sitting
  around a dining table
• When they get hungry, they try to eat the
  spaghetti
• There is only one fork to the left of each
  philosopher
• Each philosopher must acquire two forks to eat
• One philosopher can begin eating if the neighbour
  to the right has put down the fork
• No deadlock, no snatching, no starvation

48
Dining Philosophers Problem
Do you have any fantastic methods?
49
Possible Methods

• Buy 5 another forks
• Teach them to eat using just one fork
• Or One by one
• All are not cost-effective

50
Solution With Semaphores

• semaphore fork5 1
• void philosopher(int i)
• while (true)
• think()
• wait(forki)
• wait(fork(i1) mod 5)
• eat()
• signal(fork(i1) mod 5)
• signal(forki)
• All philosophers may starve to death!! Why?? (If
  they pick their left fork at same time)

51
The Dining Philosophers Problem

• A solution admit only 4 philosophers at a time
  to the table
• 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 numb. of philosophers sitting at
  the table
• Initialize T.count4

Process Pi while think wait(T)
wait(forki) wait(forki1 mod 5) eat
signal(forki1 mod 5) signal(forki)
signal(T)
52
The dining philosophers problem

• Each process needs two resources
• Every resource is mutual to two processes - i.e.
  every pair of processes compete for a specific
  resource
• Every process can either be assigned two
  resources or none at all
• Every process that is waiting for its two
  resources should sleep (be blocked)
• Every process that releases its two resources
  must wake-up the two competing processes for
  these resources, if they are interested.

53
The dining philosophers problem

• define N 5
• define LEFT (i-1) N
• define RIGHT (i1) N
• define THINKING 0
• define HUNGRY 1
• define EATING 2
• int stateN
• semaphore mutex 1
• semaphore sN / per each philosopher /
• void philosopher(int i)
• while(TRUE)
• think()
• pick_sticks(i)
• eat()
• put_sticks(i)

54
pick_sticks(i) , put_sticks(i), test(i)

• void pick_sticks(int i)
• wait(mutex) / enter CS /
• statei HUNGRY
• test(i) / try for 2 sticks /
• signal(mutex) / exit CS /
• wait(s i ) / block if sticks were not
  acquired../
• void put_sticks(int i)
• wait(mutex)
• statei THINKING / finished eating../
• test(LEFT) / can left neighbour eat now ? /
• test(RIGHT) / .. RIGHT.. ? /
• signal(mutex)
• void test(int i)
• if(statei HUNGRY stateLEFT ! EATING
  stateRIGHT ! EATING)
• statei EATING
• signal(s i )

55
Dining Philosophers Deadlocks Starvation

• the solution is deadlock-free because every
  process has either two resources or none
• for deadlock a process must have one resource and
  block for the other that is owned by another
  process (which is blocked waiting for the first)
• Starvation is possible
• Process 1 2 3 4 5
• eating-state e e
• e e
• e e
• e e

?
56
UNIX Concurrency Mechanisms

• Pipes
• Messages
• Shared memory
• Semaphores
• Signals

57
Pipes

• Based on producer-consumer model
• A pipe is a FIFO queue written by one process and
  read by another
• Writing process is blocked if no room
• Mutual exclusion is enforced by UNIX
• E.G.
• ls -l grep mbox
• Ls l gt out.txt

58
Messages

• Each process has a mailbox, an associated
  message queue
• System calls are provided for message passing
• Process sending message to a full queue is
  suspended
• Int Msgget(key_t key, int msgflg) create a msg
  queue
• Msgsnd() send
• Msgrcv() receive

59
Shared Memory and Semaphores

• Common block of virtual memory shared by multiple
  processes
• Fastest form of IPC
• UNIX kernel handles the semaphore operations
  atomically
• A semaphore contains
• Current value
• PID of last process that accessed it
• Number of processes waiting
• System calls are provided to handle semaphores

60
Signals

• A signal informs a process about an event
• Signals do not have priorities
• Some signals in UNIX
• SIGFPT Floating point exception
• SIGALARM Wake up after a time period
• SIGBUS Bus error

61
Solaris Thread Synchronization Primitives

• Mutual exclusion (mutex) locks
• Semaphores
• Multiple readers, single writer locks
• Condition variables
• Implemented in KLT and ULT
• Once created, either enter or release
• Kernel does not enforce mutual exclusion and
  unlocking on abort of threads

62
Solaris Mutex Locks and Semaphores

• If a thread has locked a mutex, only this thread
  will unlock it
• If another thread approaches the mutex, it will
  be either blocked or wait in a spin wait loop
• Use mutex_tryenter() to do busy waiting
• Solaris provides sema_P(), sema_v() and
  sema_tryp() primitives for semaphores

63
(No Transcript)
64
Readers/Writer and Condition Variables

• Readers/writer lock allows read-only access for
  an object protected by this lock
• If a thread is writing, all others must wait
• Condition variables are used with mutex locks
• Wait until a condition is true

65
(No Transcript)
66
Windows 2000 Concurrency Mechanisms

• Process
• Thread
• File
• Console input
• File change notification
• Mutex
• Semaphore
• Event
• Waitable timer

67
W2K Summary

• Objects 5 through 9 are designed for supporting
  synchronization
• Each of these objects can be in a signaled or
  unsignaled state
• A thread issues wait request to W2K, using the
  handle of the object
• When an object enters signaled state, threads
  waiting on it are released

68
W2K Example

• A thread requests wait on a file that is
  currently open
• The thread is blocked
• The file is set to signaled state when the I/O
  operation completes
• The waiting thread is released

69
Summary

• Deadlock is the permanent blocking of a set of
  processes either that compete for system
  resources or communicate with each other
• The necessary and sufficient conditions of
  deadlock are Mutual exclusion, Hold-and-wait, No
  preemption, and Circular wait
• There are four general approaches to dealing with
  deadlocak, i.e. prevention, avoidance, detection,
  and ostrich, from conservative end to the most
  liberal one
• The deadlock state can be eliminated by some
  extraordinary actions, such as killing one or
  more processes or forcing one or more processes
  to backtrack

70
Homework

• Problems 6.3 6.12 6.13
• ?? (optional)
• ????????????????,??????N????????,????????????????
  ???????,??semaphore???????????