System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention, Avoidance, and Detection Recovering from Deadlock Combined Approach.

Slides:



Advertisements
Similar presentations
Chapter 7: Deadlocks.
Advertisements

Chapter 7: Deadlocks.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 7: Deadlocks.
7.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 7: Deadlocks.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Lecture 12: Deadlocks (Chapter 7)
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 7: Deadlocks.
Lecture 7: Deadlocks, Deadlock Risk Management. Lecture 7 / Page 2AE4B33OSS Silberschatz, Galvin and Gagne ©2005 Contents The Concept of Deadlock Resource-Allocation.
Deadlocks CS 3100 Deadlocks1. The Deadlock Problem A set of blocked processes each holding a resource and waiting to acquire a resource held by another.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 8: Deadlocks System Model Deadlock Characterization Methods for Handling Deadlocks.
Chapter 7. Deadlocks.
1 Chapter 7: Deadlock. 2 The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance.
Chapter 8: Deadlocks System Model Deadlock Characterization
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts - 7 th Edition, Feb 14, 2005 Chapter 7: Deadlocks The Deadlock.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 7: Deadlocks.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 7: Deadlocks.
Deadlocks Gordon College Stephen Brinton. Deadlock Overview The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks.
1 School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Ch 7: Deadlock Dr. Mohamed Hefeeda.
What we will cover…  The Deadlock Problem  System Model  Deadlock Characterization  Methods for Handling Deadlocks  Deadlock Prevention  Deadlock.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts - 7 th Edition, Feb 14, 2005 Objectives Understand the Deadlock.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Deadlocks.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 8: Deadlocks System Model Deadlock Characterization Methods for Handling Deadlocks.
Chapter 7: Deadlocks Adapted to COP4610 by Robert van Engelen.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 7: Deadlocks.
Chapter 7 Deadlocks. 7.2 Modified By Dr. Khaled Wassif Operating System Concepts – 7 th Edition Silberschatz, Galvin and Gagne ©2005 Chapter 7: Deadlocks.
Cosc 4740 Chapter 6, Part 4 Deadlocks. The Deadlock Problem A set of blocked processes each holding a resource and waiting to acquire a resource held.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-6 Deadlocks Department of Computer Science and Software Engineering.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 AE4B33OSS Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock Characterization.
CHAPTER 8: DEADLOCKS System Model Deadlock Characterization
 The Deadlock Problem  System Model  Deadlock Characterization  Methods for Handling Deadlocks  Deadlock Prevention  Deadlock Avoidance  Deadlock.
Dr. Kalpakis CMSC 421, Operating Systems Deadlocks.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks System Model Deadlock Characterization Methods.
Lecture 12 Handling Deadlock – Prevention, avoidance and detection.
Mi-Jung Choi Dept. of Computer and Science Silberschatz, Galvin and Gagne ©2006 Operating System Principles Chapter 7: Deadlocks.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 7: Deadlocks.
Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill Technology Education Lecture 7 Operating Systems.
Operating Systems Unit VI Deadlocks and Protection Department of Computer Science Engineering and Information Technology.
Chapter 8 Deadlocks. Objective System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection.
Chapter 7: Deadlocks. 7.2CSCI 380 – Operating Systems Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock Characterization Methods for Handling.
7.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock Characterization.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
CS307 Operating Systems Deadlocks Fan Wu Department of Computer Science and Engineering Shanghai Jiao Tong University Spring 2012.
國立台灣大學 資訊工程學系 Chapter 7: Deadlocks. 資工系網媒所 NEWS 實驗室 Chapter Objectives To develop a description of deadlocks, which prevent sets of concurrent processes.
Chap 7 Deadlocks. Chapter Objectives To develop a description of deadlocks, which prevent sets of concurrent processes from completing their tasks To.
1 CS.217 Operating System By Ajarn..Sutapart Sappajak,METC,MSIT Chapter 6 Deadlocks Slide 1 Chapter 6 Deadlocks.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 8: Deadlocks System Model Deadlock Characterization Methods for Handling Deadlocks.
Deadlocks Introduction to Operating Systems: Module 7.
7.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 7: Deadlocks.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter Objectives To develop a description of deadlocks, which.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
7.1 CSE Department MAITSandeep Tayal 7: Deadlocks System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 7: Deadlocks.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts - 7 th Edition, Feb 14, 2005 Chapter 7: Deadlocks The Deadlock.
CSE Operating System Principles Deadlocks. CSE – Operating System Principles2 Overview System Model Deadlock Characterization Methods for.
Chapter 7: Deadlocks. The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 7: Deadlocks.
Chapter 7: Deadlocks.
OPERATING SYSTEM CONCEPTS AND PRACTISE
Chapter 7: Deadlocks.
Chapter 7: Deadlocks.
G.Anuradha Ref:- Galvin
Chapter 7: Deadlocks.
Outline Deadlocks, dead lock prevention, avoidance.
Deadlock Prevention Restrain the ways request can be made.
Chapter 7: Deadlocks.
Chapter 7: Deadlocks.
Presentation transcript:

System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention, Avoidance, and Detection Recovering from Deadlock Combined Approach to Deadlock Handling

 A set of blocked processes each: ◦ holding and waiting to acquire a resource held by another process in the set.  Example ◦ System has 2 tape drives. ◦ P1 and P2 each hold one tape drive and each needs another one.

 Example: ◦ semaphores Q and S, initialized to 1 P0 P1 wait(S);wait(Q); wait(Q);wait(S); … … signal(S);signal(Q); signal(Q)signal(S);

 Traffic only in one direction.  Resource: each section of a bridge.  If deadlocked: can be resolved if one car backs up (preempt resources and rollback).  Several cars may have to be backed up if a deadlock occurs.  Starvation is possible.

 Resource types R 1, R 2,..., R m  CPU cycles, memory space, I/O devices  Each resource type R i has W i instances.  Each process utilizes a resource as follows: ◦ request ◦ use ◦ release

 Mutual exclusion: ◦ only one process at a time can use a resource.  Hold and wait: ◦ a process holding at least one resource is waiting to acquire additional resources held by other processes. Deadlock may arise if 4 conditions hold simultaneously:

3. No preemption: ◦ a resource can be released only voluntarily by the process holding it, after that process has completed its task. 4. Circular wait: ∃ a set {P 0, P 1, …, P n } of waiting processes s.t.: ◦ P 0 is waiting for a resource that is held by P 1, ◦ P 1 is waiting for a resource that is held by P 2, …, ◦ P n–1 is waiting for a resource that is held by P n, and ◦ P n is waiting for a resource that is held by P 0.

 A set of vertices V and a set of edges E.  V is partitioned into two types: ◦ P = {P 1, P 2, …, P n }, the set consisting of all the processes in the system. ◦ R = {R 1, R 2, …, R m }, the set consisting of all resource types in the system.  request edge – directed edge P 1  R j  assignment edge – directed edge R j  P i

 Process:  Resource Type with 4 instances:  Pi requests instance of Rj  Pi is holding an instance of Rj PiPi RjRj PiPi RjRj

 If graph contains no cycles  no deadlock.  If graph contains a cycle  ◦ if only one instance per resource type, then deadlock. ◦ if several instances per resource type, possibility of deadlock.

1. Ensure that the system will never enter a deadlock state. 2. Allow the system to enter a deadlock state and then recover. 3. Ignore the problem and pretend that deadlocks never occur in the system; ◦ Approach used by most operating systems, including UNIX and Windows.

Restrain the ways request can be made, such that one of the 4 conditions (from earlier) cannot happen: ➊ Mutual Exclusion (mutex) ◦ do not require mutex for sharable resources  (potential problems?); ◦ must hold for nonsharable resources.

➋ Hold and Wait ◦ whenever a process requests a resource, it does not hold any other resources. Can be done by requiring either: 1.must request and be allocated all its resources before it begins execution, or 2.allow requests only when the process has none. ◦ low resource utilization; starvation possible.

➌ No Preemption ◦ Must release all currently held resources if process requests another resource that cannot be immediately allocated to it. ◦ Preempted resources are added to the list of resources for which the process is waiting. ◦ Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting.

➍ Circular Wait ◦ impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration. i.e. F(DVD Drive) = 1 F(disk drive) = 5 F(printer) = 12 If you have a resource, can only request resources with larger numbers. If you need something “smaller”, you have to release first.

 Requires that the system has some additional a priori information available:  Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need.

 Dynamically examines the resource- allocation state to ensure that there can never be a circular-wait condition.  Resource-allocation state is defined as: ◦ the number of available and allocated resources, and the maximum demands of the processes.

 When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state.  System is in safe state if there exists a safe sequence of all processes.

 Sequence is safe if: ◦ for each P i, the resources that P i can still request can be satisfied by: currently available resources + resources held by all P j, with j<i.

◦ If P i resource needs are not immediately available, then P i can wait until all P j have finished. ◦ When P j is finished, P i can obtain needed resources, execute, return allocated resources, and terminate. ◦ When P i terminates, P i+1 can obtain its needed resources, and so on.

 If a system is in safe state  no deadlocks.  If a system is in unsafe state  possibility of deadlock.  Avoidance  ensure that a system will never enter an unsafe state.

 Claim edge (dashed line) P i  R j means: ◦ process P j may request resource R j.  Claim edge converts to request edge when a process requests a resource.  When a resource is released by a process, assignment edge reconverts to a claim edge.  Resources must be claimed a priori in the system.

 Multiple instances.  Each process must a priori claim maximum use. (just like above)  When a process requests a resource it may have to wait.  When a process gets all its resources it must return them in a finite amount of time.

 n = # of processes  m = # of resources types.  Available: ◦ Vector of length m. ◦ if available[j] = k  k instances of resource type R j available.  Max: ◦ n x m matrix. If Max[i,j] = k, then process P i may request at most k instances of resource type R j.

 Allocation: ◦ n x m matrix. ◦ if Allocation[i,j] = k  P i has k instances of R j.  Need: ◦ n x m matrix. ◦ if Need[i,j] = k  P i may need k more instances of R j. Need [i,j] = Max[i,j] – Allocation [i,j].

➊ Work, Finish: vectors of length m and n, respectively. ◦ Initialize:  Work = Available  Finish [i] = false; ∀i ➋ Find an i such that both: ◦ (a) Finish [i] = false ◦ (b) Need[i]  Work ◦ If no such i exists, go to step ➍ ➌ Work = Work + Allocation[i] Finish[i] = true go to step ➋ ➍ If Finish [i] == true for all i, then the system is in a safe state.

 Request i = request vector for process P i.  Request i [j] = k  P i wants k instances of resource type R j. ➊ if Request i  Need i go to step 2.  else raise error condition (exceeded maximum claim) ➋ if Request i  Available, go to step 3. ◦ else P i must wait; (resources unavailable)

➌ Pretend to allocate requested resources to Pi by modifying the state as follows:  Available = Available - Request i ;  Allocation i = Allocation i + Request i ;  Need i = Need i – Request i  Then run safety algorithm:  if safe  the resources are allocated to Pi.  if unsafe  Pi must wait, and the old resource-allocation state is restored

 5 processes P 0 through P 4  3 resource types: A (10 instances), B (5 instances), and C (7 instances).

Snapshot at time T 0 : AllocationMax Available Need A B C A B C A B CA B C P P P P P Need = Max – Allocation

 The system is in a safe state since the sequence: satisfies the safety criteria.  (Is there another safe sequence?)

AllocationNeedAvailable A B CA B CA B C P P P P P Can request for (1,0,2) by P1 be granted? Can request for (3,3,0) by P4 be granted? Can request for (0,2,0) by P0 be granted?

 Allow system to enter deadlock state  Detection algorithm  Recovery scheme

 Maintain wait-for graph ◦ Nodes are processes. ◦ P i  P j means P i is waiting for P j.  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 n 2 operations, where n is the number of vertices in the graph.

 Available: ◦ A vector of length m indicates the # of available resources of each type.  Allocation: ◦ n x m matrix that defines the # of resources of each type currently allocated to each process.

 Request: ◦ n x m matrix for the current request of each process.  Request [i,j] = k,  P i is requesting k more instances of resource type. R j.

 Work, Finish: vectors of length m and n, respectively  ➊ Initialize: ◦ (a) Work = Available ◦ (b) for (i = 1,2, …, n) if Allocation i  0 Finish[i] = false else Finish[i] = true  ➋ Find an index i such that both: ◦ (a)Finish[i] == false ◦ (b)Request i  Work ◦ if no such i exists, goto ➍.

 ➌ Work = Work + Allocation i Finish[i] = true go to ➋.  ➍ if Finish[i] == false, for some i, then the system is in a deadlock state. if Finish[i] == false, then Pi is deadlocked Algorithm requires O(m x n 2) operations to detect deadlocks.

 Five processes P 0 through P 4 ; three resource types A (7 instances), B (2 instances), and C (6 instances).  Snapshot at time T 0 : Allocation Request Available A B C A B C A B C P P P P P Sequence will result in Finish[i] = true, ∀ i.

 P 2 requests an additional instance of type C. RequestAvailableA B C P P P P P  State of system? ◦ Can reclaim resources held by process P 0, but insufficient resources to fulfill other processes; requests. ◦ Deadlock exists, consisting of processes P 1, P 2, P 3, and P 4.

 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?  one for each disjoint cycle  If invoked arbitrarily, there may be many cycles in the resource graph: ◦ which of the many deadlocked processes “caused” deadlock?

 Abort all deadlocked processes.  Abort one process at a time until the deadlock cycle is eliminated.  In which order should we choose to abort? ◦ Priority of the process. ◦ How long process has computed, and how much longer to completion. ◦ Resources the process has used. ◦ Resources process needs to complete. ◦ How many processes will need to be terminated. ◦ Is process interactive or batch?

 Selecting a victim – minimize cost.  Rollback – return to some safe state, restart process for that state.  Starvation – same process may always be picked as victim, include number of rollback in cost factor.

 Combine the three basic approaches ◦ prevention ◦ avoidance ◦ detection  allowing the use of the optimal approach for each of resources in the system.

 Partition resources into hierarchically ordered classes.  Use most appropriate technique for handling deadlocks within each class.