CS 333 Introduction to Operating Systems Class 7
- Slides: 85
CS 333 Introduction to Operating Systems Class 7 - Deadlock Jonathan Walpole Computer Science Portland State University 1
Resources and deadlocks q q q Processes need access to resources in order to make progress Examples of computer resources v printers v disk drives v kernel data structures (scheduling queues …) v locks/semaphores to protect critical sections Suppose a process holds resource A and requests resource B v at the same time another process holds B and requests A v both are blocked and remain so … this is deadlock 2
Deadlock modeling: resource usage model Sequence of events required to use a resource q v v v request the resource (like acquiring a mutex lock) use the resource release the resource (like releasing a mutex lock) Must wait if request is denied q v v v block busy wait fail with error code 3
Preemptable vs nonpreemptable resources q Preemptable resources v q Nonpreemptable resources v v q can be taken away from a process with no ill effects will cause the holding process to fail if taken away May corrupt the resource itself Deadlocks occur when processes are granted exclusive access to non-preemptable resources and wait when the resource is not available 4
Definition of deadlock A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause q q Usually the event is the release of a currently held resource None of the processes can … v be awakened v run v release resources 5
Deadlock conditions q A deadlock situation can occur if and only if the following conditions hold simultaneously v v Mutual exclusion condition – resource assigned to one process only Hold and wait condition – processes can get more than one resource No preemption condition Circular wait condition – chain of two or more processes (must be waiting for resource from next one in chain) 6
Examples of deadlock 7
Resource acquisition scenarios Thread A: acquire (resource_1) use resource_1 release (resource_1) Example: var r 1_mutex: Mutex. . . r 1_mutex. Lock() Use resource_1 r 1_mutex. Unlock() 8
Resource acquisition scenarios Thread A: acquire (resource_1) use resource_1 release (resource_1) Another Example: var r 1_sem: Semaphore r 1_sem. Up(). . . r 1_sem. Down() Use resource_1 r 1_sem. Up() 9
Resource acquisition scenarios Thread A: acquire (resource_1) use resource_1 release (resource_1) Thread B: acquire (resource_2) use resource_2 release (resource_2) 10
Resource acquisition scenarios Thread A: acquire (resource_1) use resource_1 release (resource_1) Thread B: acquire (resource_2) use resource_2 release (resource_2) No deadlock can occur here! 11
Resource acquisition scenarios: 2 resources Thread A: acquire (resource_1) acquire (resource_2) use resources 1 & 2 release (resource_2) release (resource_1) Thread B: acquire (resource_1) acquire (resource_2) use resources 1 & 2 release (resource_2) release (resource_1) 12
Resource acquisition scenarios: 2 resources Thread A: Thread B: acquire (resource_1) acquire (resource_2) use resources 1 & 2 release (resource_2) release (resource_1) No deadlock can occur here! 13
Resource acquisition scenarios: 2 resources Thread A: acquire (resource_1) use resources 1 release (resource_1) acquire (resource_2) use resource 2 release (resource_2) Thread B: acquire (resource_2) use resources 2 release (resource_2) acquire (resource_1) use resource 1 release (resource_1) 14
Resource acquisition scenarios: 2 resources Thread A: Thread B: acquire (resource_1) use resources 1 release (resource_1) acquire (resource_2) use resource 2 release (resource_2) acquire (resource_2) use resources 2 release (resource_2) acquire (resource_1) use resource 1 release (resource_1) No deadlock can occur here! 15
Resource acquisition scenarios: 2 resources Thread A: acquire (resource_1) acquire (resource_2) use resources 1 & 2 release (resource_2) release (resource_1) Thread B: acquire (resource_2) acquire (resource_1) use resources 1 & 2 release (resource_1) release (resource_2) 16
Resource acquisition scenarios: 2 resources Thread A: Thread B: acquire (resource_1) acquire (resource_2) use resources 1 & 2 release (resource_2) release (resource_1) acquire (resource_2) acquire (resource_1) use resources 1 & 2 release (resource_1) release (resource_2) Deadlock is possible! 17
Dealing with deadlock q Four general strategies v Ignore the problem • Hmm… advantages, disadvantages? v Detection and recovery v Dynamic avoidance via careful resource allocation v Prevention, by structurally negating one of the four necessary conditions 18
Deadlock detection q Let the problem happen, then recover q How do you know it happened? q Do a depth-first-search on the resource allocation graph 19
Detection: Resource Allocation Graphs Process/Thread A R Resource 20
Detection: Resource Allocation Graphs Process/Thread A “is held by” R Resource 21
Detection: Resource Allocation Graphs Resource Process/Thread A S R Resource “is requesting” 22
Detection: Resource Allocation Graphs A S R B 23
Detection: Resource Allocation Graphs A S R B Deadlock 24
Detection: Resource Allocation Graphs A S R B Deadlock = a cycle in the graph 25
Deadlock detection (1 resource of each) q Do a depth-first-search on the resource allocation graph 26
Deadlock detection (1 resource of each) q Do a depth-first-search on the resource allocation graph 27
Deadlock detection (1 resource of each) q Do a depth-first-search on the resource allocation graph 28
Deadlock detection (1 resource of each) q Do a depth-first-search on the resource allocation graph 29
Deadlock detection (1 resource of each) q Do a depth-first-search on the resource allocation graph Deadlock! 30
Mulitple units/instances of a resource q Some resources have only one “unit”. v Only one thread at a time may hold the resource. • Printer • Lock on Ready. Queue q Some resources have several units. v All units are considered equal; any one will do. • Page Frames • Dice in the Gaming Parlor problem v v A thread requests “k” units of the resource. Several requests may be satisfied simultaneously. 31
Deadlock modeling with multiple resources q Theorem: If a graph does not contain a cycle then no processes are deadlocked v v A cycle in a RAG is a necessary condition for deadlock Is it a sufficient condition? 32
Deadlock modeling with multiple resources q Theorem: If a graph does not contain a cycle then no processes are deadlocked v v A cycle in a RAG is a necessary condition for deadlock Is it a sufficient condition? 33
Deadlock detection issues q How often should the algorithm run? v On every resource request? v Periodically? v When CPU utilization is low? v When we suspect deadlock because some thread has been asleep for a long period of time? 34
Recovery from deadlock q If we detect deadlock, what should be done to recover? v v q Abort deadlocked processes and reclaim resources Abort one process at a time until deadlock cycle is eliminated Where to start? v v v Lowest priority process? Shortest running process? Process with fewest resources held? Batch processes before interactive processes? Minimize number of processes to be terminated? 35
Other deadlock recovery techniques q How do we prevent the resource becoming corrupted v q For example, shared variables protected by a lock? Recovery through preemption and rollback v Save state periodically (at start of critical section) • take a checkpoint of memory • start computation again from checkpoint – Checkpoint must be prior to resource acquisition! v Useful for long-lived computation systems 36
Deadlock avoidance q Detection vs. avoidance… v Detection – “optimistic” approach • Allocate resources • “Break” system to fix the problem if necessary v Avoidance – “pessimistic” approach • Don’t allocate resource if it may lead to deadlock • If a process requests a resource. . . make it wait until you are sure it’s OK v Which one to use depends upon the application • And how easy is it to recover from deadlock! 37
Avoidance using process-resource trajectories t 1 t 2 t 3 t 4 time Process A 38
Avoidance using process-resource trajectories Requests Printer Requests CD-RW Releases Printer Releases CD-RW t 1 t 2 t 3 t 4 time Process A 39
Process B time Avoidance using process-resource trajectories t. Z t. Y t. X t. W 40
Process B time Avoidance using process-resource trajectories t. Z Releases CD-RW Requests Printer Releases Printer Requests CD-RW t. Y t. X t. W 41
Process B time Avoidance using process-resource trajectories t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 42
Process B time Avoidance using process-resource trajectories t. Z Both processes hold CD-RW t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 43
Process B time Avoidance using process-resource trajectories Both processes hold Printer t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 44
Process B time Avoidance using process-resource trajectories Forbidden Zone t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 45
Process B time Avoidance using process-resource trajectories t. Z t. Y t. X t. W t 1 t 2 t 3 Process A time t 4 Trajectory showing system progress 46
Process B time Avoidance using process-resource trajectories B makes progress, A is not running t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 47
Process B time Avoidance using process-resource trajectories t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A B requests the CD-RW 48
Process B time Avoidance using process-resource trajectories t. Z t. Y Request is granted t. X t. W t 1 t 2 t 3 t 4 time Process A 49
Process B time Avoidance using process-resource trajectories A runs & makes a request for printer t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 50
Process B time Avoidance using process-resource trajectories t. Z t. Y t. X t. W t 1 t 2 t 3 time t 4 Process A Request is granted; A proceeds 51
Process B time Avoidance using process-resource trajectories B runs & requests the printer. . . MUST WAIT! t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 52
Process B time Avoidance using process-resource trajectories A runs & requests the CD-RW t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 53
Process B time Avoidance using process-resource trajectories A. . . holds printer requests CD-RW B. . . holds CD-RW requests printer t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 54
Process B time Avoidance using process-resource trajectories A. . . holds printer requests CD-RW B. . . holds CD-RW requests printer t. Z t. Y t. X t. W DEADLOCK! t 1 t 2 t 3 t 4 time Process A 55
Process B time Avoidance using process-resource trajectories A danger occurred here. t. Z Should the OS give A the printer, or make it wait? ? ? t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 56
Process B time Avoidance using process-resource trajectories t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A This area is “unsafe” 57
Process B time Avoidance using process-resource trajectories Within the “unsafe” area, deadlock is inevitable. We don’t want to enter this area. The OS should make A wait at this point! t. Z t. Y t. X t. W t 1 t 2 t 3 t 4 time Process A 58
Process B time Avoidance using process-resource trajectories t. Z t. Y t. X t. W t 1 t 2 t 3 Process A t 4 B requests the printer, B releases CD-RW, time B releases printer, then A runs to completion! 59
Safe states q The current state: “which processes hold which resources” q A “safe” state: v v q No deadlock, and There is some scheduling order in which every process can run to completion even if all of them request their maximum number of units immediately The Banker’s Algorithm: v v Goal: Avoid unsafe states!!! When a process requests more units, should the system grant the request or make it wait? 60
Avoidance with multiple resources Total resource vector Available resource vector Maximum Request Vector Row 2 is what process 2 might need Note: These are the max. possible requests, which we assume are known ahead of time! 61
Banker’s algorithm for multiple resources q q q Look for a row, R, whose unmet resource needs are all smaller than or equal to A. If no such row exists, the system will eventually deadlock since no process can run to completion Assume the process of the row chosen requests all the resources that it needs (which is guaranteed to be possible) and finishes. Mark that process as terminated and add all its resources to A vector Repeat steps 1 and 2, until either all process are marked terminated, in which case the initial state was safe, or until deadlock occurs, in which case it was not 62
Avoidance with multiple resources Total resource vector Available resource vector Maximum Request Vector Row 2 is what process 2 might need Run algorithm on every resource request! 63
Avoidance with multiple resources Max request matrix 64
Avoidance with multiple resources Max request matrix 65
Avoidance with multiple resources Max request matrix 66
Avoidance with multiple resources 2 2 2 0 Max request matrix 67
Avoidance with multiple resources 2 2 2 0 Max request matrix 68
Avoidance with multiple resources 2 2 2 0 4 2 2 1 Max request matrix 69
Problems with deadlock avoidance q Deadlock avoidance is often impossible v q because you don’t know in advance what resources a process will need! Alternative approach “deadlock prevention” v v Make deadlock impossible! Attack one of the four conditions that are necessary for deadlock to be possible 70
Deadlock prevention q Conditions necessary for deadlock: Mutual exclusion condition Hold and wait condition No preemption condition Circular wait condition 71
Deadlock prevention q Attacking mutual exclusion? v a bad idea for some resource types • resource could be corrupted v works for some kinds of resources in certain situations • eg. , when a resource can be partitioned q Attacking no preemption? v a bad idea for some resource types • resource may be left in an inconsistent state v may work in some situations • checkpointing and rollback of idempotent operations 72
Deadlock prevention q Attacking hold and wait? v v v Require processes to request all resources before they begin! Process must know ahead of time Process must tell system its “max potential needs” • eg. , like in the bankers algorithm • When problems occur a process must release all its resources and start again 73
Attacking the conditions q Attacking circular waiting? v v v Number each of the resources Require each process to acquire lower numbered resources before higher numbered resources More precisely: “A process is not allowed to request a resource whose number is lower than the highest numbered resource it currently holds” 74
Recall this example of deadlock Thread A: acquire (resource_1) acquire (resource_2) use resources 1 & 2 release (resource_2) release (resource_1) Thread B: acquire (resource_2) acquire (resource_1) use resources 1 & 2 release (resource_1) release (resource_2) Assume that resources are ordered: 1. Resource_1 2. Resource_2 3. . etc. . . 75
Recall this example of deadlock Thread A: acquire (resource_1) acquire (resource_2) use resources 1 & 2 release (resource_2) release (resource_1) q q q Thread B: acquire (resource_2) acquire (resource_1) use resources 1 & 2 release (resource_1) release (resource_2) Assume that resources are ordered: 1. Resource_1 2. Resource_2 3. . etc. . . Thread B violates the ordering! 76
Why Does Resource Ordering Work? q Assume deadlock has occurred. q Process A v v q Process B v v q holds X requests Y holds Y requests Z Process C v v holds Z requests X 77
Why Does Resource Ordering Work? q Assume deadlock has occurred. q Process A v v q Process B v v q holds X requests Y X<Y holds Y requests Z Process C v v holds Z requests X 78
Why Does Resource Ordering Work? q Assume deadlock has occurred. q Process A v v q Process B v v q holds X requests Y holds Y requests Z X<Y Y< Z Process C v v holds Z requests X 79
Why Does Resource Ordering Work? q Assume deadlock has occurred. q Process A v v q Process B v v q holds X requests Y v Y< Z holds Y requests Z Process C v X<Y Z<X holds Z requests X 80
Why Does Resource Ordering Work? q Assume deadlock has occurred. q Process A v v q Process B v v q holds X requests Y v This is impossible! Y< Z holds Y requests Z Process C v X<Y Z<X holds Z requests X 81
Why Does Resource Ordering Work? q Assume deadlock has occurred. q Process A v v q Process B v v q holds X requests Y v Y< Z holds Y requests Z Process C v X<Y This is impossible! Therefore the assumption must be false! Z<X holds Z requests X 82
Resource Ordering q q The chief problem: v It may be hard to come up with an acceptable ordering of resources! Still, this is the most useful approach in an OS 1. Process. Control. Block 2. File. Control. Block 3. Page Frames q Also, the problem of resources with multiple units is not addressed. 83
A word on starvation q Starvation and deadlock are two different things v v With deadlock – no work is being accomplished for the processes that are deadlocked, because processes are waiting for each other. Once present, it will not go away. With starvation – work (progress) is getting done, however, a particular set of processes may not be getting any work done because they cannot obtain the resource they need 84
Quiz q q What is deadlock? What conditions must hold for deadlock to be possible? What are the main approaches for dealing with deadlock? Why does resource ordering help? 85
- I/o device management in operating system
- Cse333
- Ece333
- Komax ims 295
- Ofc <333
- Sbr 333 kragujevac
- Uiuc ece 333
- Cse 333
- Cs333
- Byk-346
- 333 riverside drive
- Real numbers band
- Rhein inn main po eselsbrücke
- Jruby vs ruby
- Che 333
- Che 333
- 235 rounded to the nearest ten
- 333
- Geo 333
- Battle 333 bc
- Ece 333
- Examples of an os
- Evolution of operating systems
- Components of an operating system
- Os components
- Wsn operating systems
- Operating systems tree
- Operating system lab
- What is modern operating system
- Components of operating system
- Design issues in distributed system
- Early operating systems
- Real-time operating systems
- Can we make operating systems reliable and secure
- Alternative operating systems
- Exokernel operating system
- Operating systems: internals and design principles
- Operating system evolution
- Examples of network operating systems
- Msdn operating systems subscription
- Hobby os
- Embedded system characteristics
- Operating systems concepts
- Operating system history
- Layers of operating system
- System software divided into two categories
- P operating system
- Components of os
- Operating system architecture in os
- Module 4 operating systems and file management
- Modern operating systems 3rd edition
- Cs162 summer 2021
- Operating systems
- Improving the reliability of commodity operating systems
- Dual mode in os
- Operating systems
- Godmar back
- Structured computer organization
- Types of network operating system
- Mit operating systems
- Operating system lecture notes
- Types of operating systems
- Section 6 operating systems
- Section 6 operating systems
- Operating systems structure
- Operating systems overview
- Operating systems: internals and design principles
- Operating systems: internals and design principles
- Operating systems: internals and design principles
- Challenges of emerging trends in operating systems
- Meta operating systems
- Single user and multi user operating system
- Operating system final exam
- Operating systems: internals and design principles
- Nt operating systems
- Operating systems
- Function of system software
- Real time characteristics of embedded operating systems
- Operating systems
- Stand alone utility programs
- Operating systems three easy pieces solution
- Operating systems internals and design principles
- Operating systems internals and design principles
- Operating systems final exam
- "patch operating systems and applications using"
- "patch operating systems and applications using"