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 - PowerPoint PPT Presentation

Loading...

PPT – 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 PowerPoint presentation | free to download - id: 76a244-OTQ3M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

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

Description:

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 ... – PowerPoint PPT presentation

Number of Views:202
Avg rating:3.0/5.0
Slides: 63
Provided by: Tab149
Learn more at: http://www.cs.fsu.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
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 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 Integer maximum
    requirement of each resource type for each
    process
  • Allocation matrix ProcessResource
    Integer current allocation of each resource type
    for each process
  • Resource vector Resource Integer total number
    in system of each resource type
  • Allocation vector Resource Integer number
    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)
About PowerShow.com