Download presentation
Presentation is loading. Please wait.
Published byShanon Bennett Modified over 9 years ago
1
CST 352 - Operating Systems
Deadlock 4/26/2017 CST Operating Systems
2
CST 352 - Operating Systems
Topics Definitions Deadlock Conditions Ostrich Algorithm Deadlock Detection Deadlock Recovery Deadlock Avoidance Deadlock Prevention 4/26/2017 CST Operating Systems
3
CST 352 - Operating Systems
Definitions Resources – Parts of a system that are required for a process to run (e.g. memory, disk, CPU, etc.) Preemptable – A resource that can be taken from a process without adverse affects (e.g. seized memory) Non Preemtable– A resource that cannot be taken away (e.g. a device driver connected to printer) 4/26/2017 CST Operating Systems
4
CST 352 - Operating Systems
Definitions Deadlock – In a set of processes, each process is waiting for a resource that one of the other process has seized. Remember the dining philosophers. 4/26/2017 CST Operating Systems
5
CST 352 - Operating Systems
Definitions A Traffic Deadlock All Stop….. Ready….. Go! 4/26/2017 CST Operating Systems
6
CST 352 - Operating Systems
Definitions A Traffic Deadlock Oops…. Deadlock How is this deadlock avoided under normal circumstances? 4/26/2017 CST Operating Systems
7
CST 352 - Operating Systems
Definitions Question: Which of the two types of resource can lead to a deadlock condition? Why? 4/26/2017 CST Operating Systems
8
CST 352 - Operating Systems
Definition Question: Can there be deadlock in a “first-come, first-serve” scheduling scheme? 4/26/2017 CST Operating Systems
9
CST 352 - Operating Systems
Required Conditions Four conditions necessary for Deadlock: Mutual Exclusion – Only one process can access a resource at any given time. Hold and Wait – A process may hold a resource while waiting for others to become available. No preemption – No resource may be forcibly taken from a holding process. Circular wait – There must be at least two processes, each waiting for a resource held by the other. 4/26/2017 CST Operating Systems
10
CST 352 - Operating Systems
Deadlock Concepts Modeling Deadlock (grid method) X – axis: progress of process A. Y – axis: progress of process B. This gives us a good feel for deadlock overlap, however, it becomes unmanageable for more than two processes. 4/26/2017 CST Operating Systems
11
CST 352 - Operating Systems
Deadlock Concepts Modeling Deadlock (Resource Trajectories) Example: Proc A and Proc B competing for Resource 1 and Resource 2. 4/26/2017 CST Operating Systems
12
CST 352 - Operating Systems
Deadlock Concepts A Executes B Executes A Executes B acquires 2 B acquires 1 B releases 2 B releases 1 A can acquire both 1 and 2 4/26/2017 CST Operating Systems
13
CST 352 - Operating Systems
Deadlock Concepts A Executes B Executes A Executes B acquires 2 B acquires 1 A blocks on 1 B releases 2 B releases 1 A can acquire both 1 and 2 4/26/2017 CST Operating Systems
14
CST 352 - Operating Systems
Deadlock Concepts A Executes B Executes A Executes B acquires 2 A acquires 1 B blocks on 1 X A blocks on 2 Deadlock 4/26/2017 CST Operating Systems
15
CST 352 - Operating Systems
Deadlock Concepts To reduce resource contention, construct Process A such that it does not need both resource 1 and resource 2 at the same time. This increases the number of valid paths through the “gray” areas. 4/26/2017 CST Operating Systems
16
CST 352 - Operating Systems
Deadlock Concepts Modeling Deadlock (grid method) The resource trajectory model has disadvantages Unmanageable for complex systems Dependent on resource acquisition sequencing This model does suggest solutions to deadlock (e.g. avoid getting into the “Deadlock Pending” region. 4/26/2017 CST Operating Systems
17
CST 352 - Operating Systems
Deadlock Concepts Modeling Deadlock (graph method) A circle represents a process A square represents a resource A directed arch from a circle to a square represents a process requesting a resource. P1 requesting R1 A directed arch from square to circle represents a process holding a resource P1 holding R1 A Deadlock is condition is represented by a “cycle” in the graph. 4/26/2017 CST Operating Systems
18
CST 352 - Operating Systems
Deadlock Concepts Modeling Deadlock (graph method) Example: Processes P1, P2, and P3 Resources R1, R2, and R3 4/26/2017 CST Operating Systems
19
CST 352 - Operating Systems
Deadlock Concepts Modeling Deadlock (graph method) P1 requests and holds R1 P2 requests and holds R2 P3 requests and holds R3 P1 requests R2 P2 requests R3 P3 requests R1 The cyclic condition of the graph indicates this sequence of event will cause deadlock. 4/26/2017 CST Operating Systems
20
CST 352 - Operating Systems
Ostrich Algorithm Stick your head in the sand and pretend there is no problem at all. Mathematically speaking – this is unacceptable. From an engineering point of view, this may be ok. 4/26/2017 CST Operating Systems
21
CST 352 - Operating Systems
Ostrich Algorithm Considerations: What is the half-life of your OS. What resource contentions could cause a deadlock. How often statistically does your OS experience a visible deadlock. 4/26/2017 CST Operating Systems
22
CST 352 - Operating Systems
Ostrich Algorithm The Ostrich Algorithm is the easiest solution to the deadlock problem. In standard “user” based systems (e.g. Windows, Unix Workstations, etc.), this is perfectly acceptable. Would you consider the “Ostrich Algorithm” an acceptable solution for an enterprise management system? 4/26/2017 CST Operating Systems
23
CST 352 - Operating Systems
Deadlock Detection Graph based approach For each resource access Create a node representing the process accessing the resource. Create a node representing the resource. Make the appropriate directed association. 4/26/2017 CST Operating Systems
24
CST 352 - Operating Systems
Deadlock Detection Graph based approach (example) PA requests R1 and gets it. PB requests R2 and gets it. PC requests R2. PD requests R3 and gets it. PD requests R1. PA requests R3. Every time a resource request is made: Add the appropriate node to the graph Check the graph for cycles. 4/26/2017 CST Operating Systems
25
CST 352 - Operating Systems
Deadlock Detection Graph based approach To implement the graph based approach, the OS needs to: Build a graph on the fly based on resource requests. Provide some form of cycle detection to detect deadlock conditions in the constructed graph. 4/26/2017 CST Operating Systems
26
CST 352 - Operating Systems
Deadlock Detection Q: List the four conditions for deadlock. 4/26/2017 CST Operating Systems
27
CST 352 - Operating Systems
Deadlock Detection Matrix Approach Let “n” = number of processes == (P1, …, Pn). Let “m” = number of resource classes. E1 – resource of type 1 E2 – resource of type 2 … Em – resource of type m 4/26/2017 CST Operating Systems
28
CST 352 - Operating Systems
Deadlock Detection Matrix Approach At any point in time, the allocation of resources can be represented by a two vectors. (E1, E2, …, Em) – Existing resource vector. (A1, A2, …, Am) – Available resource vector. 4/26/2017 CST Operating Systems
29
CST 352 - Operating Systems
Deadlock Detection Matrix Approach Represent allocation with a matrix Columns represent resources Rows represent processes Represent requests with a matrix 4/26/2017 CST Operating Systems
30
CST 352 - Operating Systems
Deadlock Detection Matrix Approach Current Allocation and Request c11 c12 … c1m c22 c22 … c2m … … … cn1 cn2 … cnm r11 r12 … r1m r22 r22 … r2m … … … rn1 rn2 … rnm process process Current Allocation Current Request 4/26/2017 CST Operating Systems
31
CST 352 - Operating Systems
Deadlock Detection Matrix Approach At any point in time, the resource state must conform to the equation: For any j (j -> resource “column”): n cij+Aj = Ej i = 1 e.g. allocated instances of resource j + available instances of resource j = number of existing instances of resource j. 4/26/2017 CST Operating Systems
32
CST 352 - Operating Systems
Deadlock Detection Matrix Approach Process allocation is now done by comparing vectors. Vector A <= B iff For all i < m, Ai <= Bi Initialize the processes to “r” for “run”. As the algorithm proceeds, set the process flags to either “r” for processes capable of running, or “b” for processes blocked and waiting for a resource. 4/26/2017 CST Operating Systems
33
CST 352 - Operating Systems
Deadlock Detection Matrix Approach Every time there is a resource allocation: Look for a process (Pi) for which the request row (Ri) <= available resources (Ai). Looking for resource demands that can be met. If such a process is found, add the ith row of the c matrix to the A vector. Loop over next request. Else Terminate the detection algorithm and set Pi to “b” All “b” processes are blocked. 4/26/2017 CST Operating Systems
34
CST 352 - Operating Systems
Deadlock Detection Matrix Approach In practical application, keep the matrices as a running total. Each time there is a resource allocation, update the matrices. Each time there is a resource de-allocation, update the matrices. Deadlock occurs when two (or more) processes have cross referenced resources. 4/26/2017 CST Operating Systems
35
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r C = R = 1) P1 requests 2 Printers 4/26/2017 CST Operating Systems
36
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r C = R = 4/26/2017 CST Operating Systems
37
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r C = R = 2) P2 requests 1 Printer, 2 DVDs 4/26/2017 CST Operating Systems
38
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r C = R = 4/26/2017 CST Operating Systems
39
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r C = R = 3) P3 requests 1 Printer, 1 CD Rom 4/26/2017 CST Operating Systems
40
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r b C = R = 4) P3 blocked 4/26/2017 CST Operating Systems
41
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r b C = R = 5) P2 frees up printer 4/26/2017 CST Operating Systems
42
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r b C = R = 4/26/2017 CST Operating Systems
43
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r C = R = 6) P3 can now run 4/26/2017 CST Operating Systems
44
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 r C = R = 7) P1 request DVD 4/26/2017 CST Operating Systems
45
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 b r C = R = 8) P1 blocked 4/26/2017 CST Operating Systems
46
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 b r C = R = 9) P2 request printer 4/26/2017 CST Operating Systems
47
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 b r C = R = 10) P2 blocked 4/26/2017 CST Operating Systems
48
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request P1 P2 P3 b r C = R = This is still not deadlock since P3 holds a resource that could allow P2 to commence execution. If P1 held all 3 printers, we would have true deadlock. 4/26/2017 CST Operating Systems
49
CST 352 - Operating Systems
Deadlock Detection Matrix Approach (Example) Resource Vector Available Vector Printer CD Rom Printer CD Rom DVD DVD E = [ ] A = [ ] Current Allocation Request Available resources represented by different doughnuts [choc, sugar] Processes represented by people Person requests doughnut – update R matrix If possible, grant resource (doughnut) – update C matrix When doughnut is devoured, return to available vector, update C matrix P1 P2 P3 b r C = R = What are the general conditions for true deadlock? 4/26/2017 CST Operating Systems
50
CST 352 - Operating Systems
Deadlock Detection Hypothesis (extra credit – 50 pts) Prove or disprove Deadlock can be detected by rotating the rows and columns of the C and R matrix (in conjunction) so that if C and R have any inverse sub-matrices, the involved processes are deadlocked. E and A must be involved. 4/26/2017 CST Operating Systems
51
CST 352 - Operating Systems
Deadlock Recovery Given the above algorithm, the OS can detect which process is waiting for what resource. Now the OS needs to decide what to do when a deadlocked process is detected. 4/26/2017 CST Operating Systems
52
CST 352 - Operating Systems
Deadlock Recovery Recovery through preemption Take a resource away from a process and give it to another. Only works for preemptable processes. 4/26/2017 CST Operating Systems
53
CST 352 - Operating Systems
Deadlock Recovery Recovery through rollback PCB (TCB) and resource state are periodically saved at a “checkpoint” When a deadlock is detected, back the deadlocked process up to the previous stable state. Discard the resource manipulation that occurred after the checkpoint. Start the process after it is determined it can run again. 4/26/2017 CST Operating Systems
54
CST 352 - Operating Systems
Deadlock Recovery Recovery through process killing Kill off the offending processes. The processes that have allocated contending resources are removed from the system. Kill off the lower priority process. Kill off non-OS (user) processes. Return their resources to the system. 4/26/2017 CST Operating Systems
55
CST 352 - Operating Systems
Deadlock Recovery Q: How can a system be constructed so it will never have deadlock? Give an example. T or F – The graph model for deadlock only works well for 2 processes. 4/26/2017 CST Operating Systems
56
CST 352 - Operating Systems
Deadlock Avoidance Process Trajectories – revisited Shaded regions with slanted lines represent instances where both processes gain access to a resource at the same time. If the resources are mutually exclusive, it is impossible for these areas to be entered by a “run time trajectory”. 4/26/2017 CST Operating Systems
57
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm The banker at Klamath First Federal is granting a group of customers credit. The banker has limited cash to loan. Each customer has a credit limit. The banker assumes no customer will request their entire credit limit at a single time. 4/26/2017 CST Operating Systems
58
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm The banker grants loans to the customers based customer credit limit and available cash reserve. The bankers job is to avoid the situation where cash reserves drop so low that the FDIC shuts the bank down. Loans that may cause inspection by the FDIC are called “unsafe” loans. 4/26/2017 CST Operating Systems
59
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) 4 customers – Joe, Jay, Jim, and Jill Initial reserve of 10 dollars (it is a very small bank). Each customer has a credit limit. The goal here is to ensure that two customers cannot be simultaneously blocked waiting on a resource. 4/26/2017 CST Operating Systems
60
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 4/26/2017 CST Operating Systems
61
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 – granted 4/26/2017 CST Operating Systems
62
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 – granted Jay requests 1 4/26/2017 CST Operating Systems
63
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 – granted Jay requests 1 – granted 4/26/2017 CST Operating Systems
64
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 – granted Jay requests 1 – granted Jim requests 2 4/26/2017 CST Operating Systems
65
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 – granted Jay requests 1 – granted Jim requests 2 – granted 4/26/2017 CST Operating Systems
66
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 – granted Jay requests 1 – granted Jim requests 2 – granted Jill requests 4 4/26/2017 CST Operating Systems
67
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 – granted Jay requests 1 – granted Jim requests 2 – granted Jill requests 4 – granted 4/26/2017 CST Operating Systems
68
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) At any point in time, in this scenario, the states are safe because, with at least two units left, the banker can delay granting any requests until Jim pays back his loan. Jim can ask for the additional 2 dollars. 4/26/2017 CST Operating Systems
69
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) When Jim pays back his loan, the banker can lend to Jay or Jill. 4/26/2017 CST Operating Systems
70
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Unsafe State Example Joe requests 1 – granted Jay requests 2 – granted 4/26/2017 CST Operating Systems
71
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Unsafe State Example Joe requests 1 – granted Jay requests 2 – granted Jim requests 2 4/26/2017 CST Operating Systems
72
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Unsafe State Example Joe requests 1 – granted Jay requests 2 – granted Jim requests 2 – granted 4/26/2017 CST Operating Systems
73
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Unsafe State Example Joe requests 1 – granted Jay requests 2 – granted Jim requests 2 – granted Jill requests 4 4/26/2017 CST Operating Systems
74
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Unsafe State Example Joe requests 1 – granted Jay requests 2 – granted Jim requests 2 – granted Jill requests 4 With a reserve of 1, potentially, any other request could be denied. If the banker gives the loan to Jill, the reserve will be down to 1. 4/26/2017 CST Operating Systems
75
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (Example) Joe requests 1 – granted Jay requests 2 – granted Jim requests 2 – granted Jill requests 4 Granting Jill the loan would force the system into an unsafe state. If all customers demanded their maximum loan, none of them could be granted, forcing the FDIC to come down on the bank (deadlock). 4/26/2017 CST Operating Systems
76
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (multiple resource) The bankers algorithm for multiple resource is just a modification of the matrix approach for deadlock detection. The modification made relates to what the scheduler does during the application of the algorithm. Rather than waiting for deadlock to occur, the scheduler takes proactive action during resource allocation and de-allocation. 4/26/2017 CST Operating Systems
77
CST 352 - Operating Systems
Deadlock Avoidance Bankers Algorithm (multiple resource) The problem with the bankers algorithm for deadlock avoidance is to operate correctly, the resources must be pre-determined and stable. There are no systems where resources are all pre-determined and infinitely stable. 4/26/2017 CST Operating Systems
78
CST 352 - Operating Systems
Deadlock Prevention Attack mutual exclusion condition Do not allow any resources to be mutually exclusive. Printer spooling was introduced to do this. 4/26/2017 CST Operating Systems
79
CST 352 - Operating Systems
Deadlock Prevention Attack the hold and wait condition Do not allow any process to seize a resource and hold it. Require all processes to request their resources up-front. This solution introduces inefficiencies. 4/26/2017 CST Operating Systems
80
CST 352 - Operating Systems
Deadlock Prevention Attack the No-Preempt condition It is close to impossible to get rid of all non-preemptable resources in a system. 4/26/2017 CST Operating Systems
81
CST 352 - Operating Systems
Deadlock Prevention Attack the Circular wait condition Only allow a process one resource at a time. Require process to adhere to a resource numbering scheme sequential allocation 4/26/2017 CST Operating Systems
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.