Deadlock with powerpoint notes Because deadlock is a difficult concept that often looks easy. I have provided yet MORE notes on deadlock extracted from previous notes of Dr. Baker and myself. They are provided as a good reivew to assure you

1
Deadlockwith powerpoint notesBecause
deadlock is a difficult concept that often looks
easy. I have provided yet MORE notes on deadlock
extracted from previous notes of Dr. Baker and
myself. They are provided as a good reivew to
assure you understand deadlock.
2
Deadlock Topics

• Definition Deadlock
• Necessary conditions for deadlock
• Strategies for dealing with deadlock
• Strategies for detecting deadlock
• Deadlock in different models of resource
  allocation

3
Types of Resources

• Reusable
• Consumable

4
Reusable Resources

• Fixed number of units
• Neither created nor destroyed
• Used by one process at a time and not depleted by
  that use
• Processes obtain resources that they later
  release for reuse by other processes
• several different possible modes of access
• exclusive
• read/write (can be modeled by multi-unit)
• shared (not treated by text)
• operations request, grant/acquire, release
• Deadlock occurs if each process holds one
  resource and requests the other

5
Consumable Resources

• Created (produced) by a process
• Destroyed (consumed) by a process
• Operations request/receive (implies consume),
  produce/send
• Deadlock may occur if the receive operation can
  block
• Potential deadlock situations are more difficult
  to detect, and reproduce, by testing

6
Deadlock Example with Reusable Resources
Process P1
request(R1) ... request(R2) ... release(R2) ... release(R1)
  R1 critical section R1 critical section R1 critical section R1 critical section R1 critical section R1 critical section
      R2 critical section R2 critical section    
Process P2
request(R2) ... request(R1) ... release(R1) ... release(R2)
      R1 critical section R1 critical section    
  R2 critical section R2 critical section R2 critical section R2 critical section R2 critical section R2 critical section
7
Resource Allocation Graph of a Deadlocked System
8
Deadlock Trajectory Diagram
9
Example of Deadlock with Consumable Resources
P1 P2
.. ..
receivefrom(P2, M2) receivefrom(P1, M1)
..
sendto(P2, M1) sendto(P1, M2)
Deadlock occurs if the receive from operation is
blocking.
10
Natural Questions about Deadlock

• What are the fundamental causes of deadlock?
• How can we deal with deadlock?

Now that we have looked at examples of some
specific cases of deadlock, it is time to look at
deadlock from a general point of view.
11
The 4 Necessary Conditions for Deadlock

• Exclusive access (mutual exclusion)
• only one process may use a resource at a time
• Wait while holding (hold-and-wait)
• A process can continue to hold a resource while
  requesting another
• No preemption
• A process cannot be forced to give up resources
  before it chooses to give them up
• Circular wait
• There is a cycle of hold-and-wait relationships

12
The 3 Approches/Strategies for Dealing with
Deadlock

• Prevention - apply design rules to insure it can
  never occur
• Avoidance - dynamically steer around deadlocks
• Detection - hope deadlocks will not occur, but
  recover when one does

13
Deadlock Prevention Approaches

• All of the four conditions are necessary for
  deadlock to occur.Hence, by preventing any one
  of them we prevent deadlock.
• Exclusive access (mutual exclusion)
• redesign to eliminate the need for mutual
  exclusion(Can you think of an example?)
• Wait while holding (hold-and-wait)
• If a process holding resources is denied a
  further request, the process must release all its
  resources and rerequest them
• Require that a process request all of its
  required resources at one time
• No preemption
• If a process requests a resource that is
  currently held by another process, the OS
  preempts the second process and requires it to
  release its resources
• Circular wait
• Define a linear ordering of resources and require
  allocations be requested only in this order

14
Cycle Implies Different Allocation Orders
15
Ordered Allocation
16
Trajectory Diagram for Ordered Allocation
17
Release Before Request
18
Request All at Once
19
Deadlock Avoidance

• A decision is made dynamically whether the
  current resource allocation request will, if
  granted, potentially lead to a deadlock
• Requires knowledge of worst-case future process
  requests
• Approaches
• Postpone starting a process if its demands might
  lead to deadlock,i.e. while resources it may
  need are held by others
• Postpone granting an incremental resource request
  to a process if granting the allocation might
  lead to deadlock

20
Requirements for 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

21
System with Potential for Deadlock
Process P1            
request(R1) ... request(R2) ... release(R2) ... release(R1)
  R1 critical section R1 critical section R1 critical section R1 critical section R1 critical section R1 critical section
      R2 critical section R2 critical section    
Process P2            
request(R2) ... request(R1) ... release(R1) ... release(R2)
      R1 critical section R1 critical section    
  R2 critical section R2 critical section R2 critical section R2 critical section R2 critical section R2 critical section
22
Trajectory to Unsafe State
23
Resource Allocation State Transition Diagram
24
How Deadlock Is Avoided
25
How do we know a state is safe?

• Start in the given state
• Simulate running each process to completion,by
  allocating its maximum resource requirements,and
  then releasing all resources
• If all processes can complete, the state is safe

26
Representing State as Set of Tables

• Claim matrix ProcessResource Integermaximum
  requirement of each resource type for each
  process
• Allocation matrix ProcessResource
  Integercurrent allocation of each resource type
  for each process
• Resource vector Resource Integertotal number
  in system of each resource type
• Allocation vector Resource Integernumber
  currently available of each resource type

27
Determination of a Safe State initial state
28
Determination of a Safe State P2 runs to
completion
29
Determination of a Safe State P1 runs to
completion
30
Determination of a Safe State P3 runs to
completion
31
An Unsafe State initial state
32
An Unsafe State P1 requests one unit each of R1
and R3
33
How to Detect Deadlock?

• Similar to detecting an unsafe state
• Simulate execution of unblocked processes,
  assuming they will complete and release all
  resources

34
Deadlock Detection with Tables
35
Deadlock Detection with Tables (Step 2)
36
When Deadlock is Detected

• Abort all deadlocked processes
• Back up each deadlocked process to some
  previously defined checkpoint, and restart it
  from the checkpoint
• original deadlock may reoccur
• Kill deadlocked processes until deadlock no
  longer exists
• Preempt resources until deadlock no longer exists
  

37
Choose which Process to Abort

• 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

38
Graph Models of System Resource Allocation States

• Wait-for graphs (WFG)
• Single-unit resource allocation graphs
• Multi-unit resource allocation graphs
• General resource allocation graphs (GRG)

39
Wait-For Graphs (WFG)

• Nodes correspond to processes (only).

40
Single-Unit Resource Allocation Graphs
41
Multiunit Resource Allocation Graphs
42
Dining Philosophers
43
Example
Dining Philosophers Problem
44
What is the Dining Philosophers Problem?
45
Significance of this Problem

• Potential for deadlock and starvation
• Academic benchmark for evaluation and
  comparison of synchronization and mutual
  exclusion mechanisms
• An example for demonstrating various process
  and thread synchronization mechanisms
• A good solution has no deadlock or starvation

46
Possibility of Deadlock
47
Possibility of Starvation
48
Review of Monitor Concept

• Encapsulated data objects and procedures(a.k.a.
  methods or functions)
• Per-monitor lock enforces mutual exclusion
• Only one thread may be executing in the monitor
  at a time
• Thread inside the monitor may reliquish the
  monitor lock to wait for a condition
• POSIX mutex and CVs designed to implement
  monitors

49
Dining Philosophers Solution as Monitor
int update_state (int i) if (statei
HUNGRY stateLEFT ! EATING
stateRIGHT ! EATING) statei
EATING pthread_cond_signal (CVi)
return 0
50
Dining Philosophers Solution as Monitor
voidchopsticks_take (int i)
pthread_mutex_lock (M) statei HUNGRY
update_state(i) while (statei
HUNGRY) pthread_cond_wait (CVi,M)
pthread_mutex_unlock (M)
voidchopsticks_put (int i)
pthread_mutex_lock (M) statei
THINKING update_state (LEFT)
update_state (RIGHT) pthread_mutex_unlock
(M)
51
The Complete Code

• Some of the code examples for dining philosophers
  include
• chopsticks.h, the monitor interface
• chopsticks0.c, the monitor implementation
• philosophers_t.c, the main program
• The full code for this solution is in the
  indicated files.

52
Dining Philosopher Solution with Binary
Semaphores,

• void chopsticks_take (int i)
• if (i (NTHREADS - 1))
• lock (0) lock (NTHREADS - 1)
• else
• lock (i) lock ((i 1) NTHREADS)
• void chopsticks_
• put (int i)
• unlock (i)
• unlock ((i 1) NTHREADS)

53
Unix Mutual Exclusion Mechanisms

• lockfiles (e.g., see open(...O_CREAT
  O_EXCL...))
• System V semaphores (e.g., see sema_wait)
• POSIX semaphores (e.g., see sem_wait)
• File record locking (e.g., see flock(), lockf,
  and fcntl(...F_SETFL...))
• POSIX mutexes, with attribute PTHREAD_PROCESS_SHAR
  ED

54
Lockfile Implementation of Binary Semaphore

• void lock (int i)
• int fildes
• while ((fildes open (lockfilenamei, O_RDWR
  O_CREAT O_EXCL, S_IRUSR S_IWUSR))-1)
• if (errno ! EEXIST)
• chopsticks_emergency_stop()
• CHECK (usleep (100))
• close (fildes)
• void unlock (int i)
• CHECK (unlink (lockfilenamei) -1)

55
Weaknesses of this Solution

• How do we choose the length of time to sleep?
• What happens if it is too long?
• What happens if it is too short?
• What happens if the process dies while holding a
  lock?
• Keep all maskable signals masked while holding a
  lockfile(see explanation of signals later)
• Time out when waiting for a lockfile, and then
  steal the lock

56
How good is this solution?

• Is this solution subject to deadlock? If not, why
  not?
• Is this solution subject to starvation? Why or
  why not?
• Which of the defects of this solution, if any, is
  due to the lockfile implementation, versus the
  way the binary semaphores are used in the
  solution?

57
Dining Philosopher Lockfile Solution Complete Code

• The code is included below
• chopsticks.h defines the interface
• chopsticks1.c is the implementation
• philosophers.c is a test driver main program

58
Variant Solution, using sigsuspend()

• For another solution
• chopsticks2.c is the alternate implementation

59
Counting Semaphores
60
Semaphores, versus Mutexes CVs 

• The POSIX thread synchronization objects, mutexes
  and condition variables, are a more recent
  invention than some other synchronization
  mechanisms. Using them, one can solve any problem
  that can be solved using other mechanisms. Here,
  we show how they can be used to implement one of
  the earliest and best known types of
  synchronization objects semaphores.

61
Counting Semaphore (Stallings' version)

• A type of synchronization object
• Atomically counts available resources, and waits
  for resources to become available
• Holds an integer value, called the countlt which
  is initially non-negative
• Has an associated queue of waiting procesess
• Operations
• decrement, also known as P, down, and wait
• s.count--if (s.count lt 0) enqueue and block
  this process
• increment, also known as V, up, post, and signal
• s.countif (s.count lt 0) dequeue and unblock
  one process

62
Implementation of Linux/POSIX Semaphore as
Monitor, using Mutex CV
typdef struct counting_semaphore pthread_mutex_t M pthread_cond_t CV int value sem_ tvoid semaphore_wait () pthread_mutex_lock (S.M) while (S.value 0) pthread_cond_wait (S.CV, S.M) S.value-- pthread_mutex_unlock (S.M) void semaphore_signal () pthread_mutex_lock (S.M) S.value if (S.value 1) pthread_cond_signal (S.CV) pthread_mutex_unlock (S.M)