Presentation is loading. Please wait.

Presentation is loading. Please wait.

DeadlocksDeadlocks CS 3060. Imagine a narrow set of stairs, only wide enough for one person to pass. However, the landings are big enough for several.

Similar presentations


Presentation on theme: "DeadlocksDeadlocks CS 3060. Imagine a narrow set of stairs, only wide enough for one person to pass. However, the landings are big enough for several."— Presentation transcript:

1 DeadlocksDeadlocks CS 3060

2 Imagine a narrow set of stairs, only wide enough for one person to pass. However, the landings are big enough for several people to stand.

3 Wait

4 Deadlock

5 Preemptable and Non-preemptable Resources A preemptable resource is one that can be temporarily taken way from the process owning it without any ill effects. A non-preemptable resource is one that cannot be taken away without causing the computation to fail.

6 Using Semaphores to Acquire and Use a Resource wait(&semaphore_1); use_resource_1; signal(&semaphore_1)

7 Using Semaphores to Acquire and Use Two Resources wait(&semaphore_1); wait(&semaphore_2); use_resource_1; use resource_2; signal(&semaphore_2); signal(&semaphore_1)

8 Two Processes Using Semaphores to Acquire and Use Two Resources wait(&semaphore_1); wait(&semaphore_2); use_resource_1; use resource_2; signal(&semaphore_2); signal(&semaphore_1) wait(&semaphore_2); wait(&semaphore_1); use_resource_1; use resource_2; signal(&semaphore_1); signal(&semaphore_2) Process A Process B

9 wait(&semaphore_1); wait(&semaphore_2); use_resource_1; use resource_2; signal(&semaphore_2); signal(&semaphore_1) wait(&semaphore_2); wait(&semaphore_1); use_resource_1; use resource_2; signal(&semaphore_1); signal(&semaphore_2) Process A Process B 1 1 0 Time slice expires… semaphore 1 semaphore 2 Two Processes Using Semaphores to Acquire and Use Two Resources

10 wait(&semaphore_1); wait(&semaphore_2); use_resource_1; use resource_2; signal(&semaphore_2); signal(&semaphore_1) wait(&semaphore_2); wait(&semaphore_1); use_resource_1; use resource_2; signal(&semaphore_1); signal(&semaphore_2) Process A Process B 1 0 0 D E A D L O C K ! semaphore 1 semaphore 2 Two Processes Using Semaphores to Acquire and Use Two Resources

11 wait(&semaphore_1); wait(&semaphore_2); use_resource_1; use resource_2; signal(&semaphore_2); signal(&semaphore_1) wait(&semaphore_2); wait(&semaphore_1); use_resource_1; use resource_2; signal(&semaphore_1); signal(&semaphore_2) Process A Process B Can you fix it so no deadlock occurs? Two Processes Using Semaphores to Acquire and Use Two Resources

12 wait(&semaphore_1); wait(&semaphore_2); use_resource_1; use resource_2; signal(&semaphore_2); signal(&semaphore_1) wait(&semaphore_1); wait(&semaphore_2); use_resource_1; use resource_2; signal(&semaphore_2); signal(&semaphore_1) Process A Process B Two Processes Using Semaphores to Acquire and Use Two Resources

13 Some Examples of Deadlock

14 Deadlock on a file request A System built for contractors has two files (among others) - one for suppliers - one for inventory It also has two applications (among others) - a purchasing application that orders material - a sales application that creates a supply list

15 Some Examples of Deadlock Deadlock on a file request Inventory Suppliers Purchasing Sales Purchasing accesses the supplier file to place an order for lumber. Sales accesses the inventory file to reserve parts to build a home ordered today. Purchasing now tries to access the Inventory file to verify the quantity of lumber on hand before placing the order Sales tries to access the supplier file to check the schedule of a subcontractor.

16 Some Examples of Deadlock Deadlock on a print spooler A print spooler accepts input from many users, but will not start a print job until it has a complete print file. spool print job The day that a big project is due everyone in class submits their print files at the same time. The spooler accepts pages from everyone so several page ones show up, then several page twos, and so on. Quickly the spool file fills. It cannot print anything because is has no complete jobs.

17 Four Conditions for Deadlock 1.Mutual exclusion condition : Each resource is either being used by exactly one process or it is available. 2. Hold and wait condition : Processes currently holding resources granted earlier can request additional new resources. 3.No preemption condition : Resources previously granted cannot be taken away from the process. The process must release them voluntarily. Once a process requests a resource that is not available, it cannot withdraw its request. 4.Circular wait condition: There must be a circular chain of two or more processes, each of which is waiting for a resource held by the next member of the chain.

18 Deadlock Modeling process resource The resource has been assigned to the process. resource process The process is blocked, waiting for the resource. This is called a Resource Graph

19 Deadlock Modeling process resource process r1 r2 p1 p2 process p1 owns resource r1 process p1 is blocked waiting for resource r2 process p2 is blocked waiting for resource r1 process p2 owns resource 2 Circular Wait Condition!

20 This Process-Resource model provides a “snapshot” of the relationships between processes and resources at some instant in time. We need a model that addresses the dynamics of the relationships … i.e. what happens over time.

21 S is the set of states {s i } where each state s is represented with a resource graph representing the processes and resources in the machine. The initial state, s 0, represents the situation Where none of the resources have been allocated. In this model we are interested in state transitions. The pattern in which resources are requested, allocated, and released will determine whether or not the system is deadlocked.

22 Process A Request resource R Request resource S Do some work Release resource R Release resource S Process B Request resource S Request resource T Do some work Release resource S Release resource T Process C Request resource T Request resource R Do some work Release resource T Release resource R Assume a Round Robin Scheduling Algorithm With events occurring in the following order: Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R

23 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST

24 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST

25 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST

26 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST

27 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST

28 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST D E A D L O C K !

29 We know that the operating system is not bound to run processes in any particular order. In this case, if the operating system knew of the impending deadlock, it could have scheduled the work differently!

30 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST

31 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST potential deadlock – block this call!

32 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST potential deadlock – block this call!

33 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST potential deadlock – block this call!

34 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R A B C RST potential deadlock – block this call! Blocked. blocks

35 Process A requests resource R Process B requests resource S Process C requests resource T Process A requests resource S Process B requests resource T Process C requests resource R Process A does its work Process A releases resource R Process A releases resource S A B C RST potential deadlock – block this call! Blocked. blocks There is no deadlock --- Process C does its work and releases its resources Process B is now unblocked

36 Deadlock Strategies The Ostrich Algorithm: Ignore the problem. If you ignore it, it may ignore you. Detection and Recovery: Let deadlocks occur, detect them and take action. Dynamic avoidance: OS is careful how it allocates resources Deadlock Prevention: Structurally negate one of the conditions necessary to cause deadlock.

37 The Ostrich Algorithm Good or Bad? Many potential deadlock situations occur because almost all resources on a system are finite. For example, The number of open files that a system can manage is limited by the size of the i-node table. Suppose that 100 processes all require 100 open files before they can do their work. After each has opened 99, the i-node table becomes full. Now, none of the processes can open another file and a deadlock occurs. How often will this situation occur? Does it occur often enough that it is worth fixing? Fixing such problems is expensive and usually involves placing inconvenient restrictions in what a process can do.

38 ReminderReminder process resource The resource has been assigned to the process. resource process The process is blocked, waiting for the resource.

39 Deadlock Detection Is there a deadlock in the drawing below? A F C R S W D B E G T U W Cycles are pretty easy to find with visual inspection. Can they be found algorithmically?

40 Resource graphs are an example of a directed graph. many algorithms exist to detect cycles in a directed graph. Repeat the following steps for each node in the graph 1.Initialize a list to the empty list. Designate all arcs as unvisited 2.Add the current node to the list. Check to see if the node appears in the list more than once. If it does a cycle exists. 3.From the given node, see if there are any outgoing arcs. If so, go to step 4. Otherwise go to step 5. 4.Pick one of the outgoing nodes at random and mark it. Follow it to the new current node and go to step 2. 5.Dead end. Remove the node from the list and go back to the previous one and make it the current node. Go to step 3. If this node is the initial node, there are no cycles.

41 Deadlock Detection Is there a deadlock in the drawing below? A F C R S W D B E G T U W Start here and go left to right, top to bottom

42 A F C R S W D B E G T U W List L R

43 A F C R S W D B E G T U W R This is the only outging arc, so A is the next node A x

44 A F C R S W D B E G T U W List L R This is the only outging arc, so S is the next node A S x x

45 A F C R S W D B E G T U W List L R S has no outgoing Arcs, so back-up To A A x x

46 A F C R S W D B E G T U W List L R A has no unmarked outgoing arcs, so back-up To R x x

47 A F C R S W D B E G T U W List L R has no unmarked outgoing arcs, so we are done inspecting this node. x x

48 A F C R S W D B E G T U W List L Move to the next node and repeat the algorithm. It should be pretty obvious that this iteration stops quickly, finding no cycle.

49 A F C R S W D B E G T U W List L Move to the next node and repeat the algorithm.

50 A F C R S W D B E G T U W List L B x This is the only outgoing arc T

51 A F C R S W D B E G T U W List L B x This is the only outgoing arc T x

52 A F C R S W D B E G T U W List L Until finally at this point we have … x x x x x x B T E W G U D

53 A F C R S W D B E G T U W List L If we go this way we hit a dead end … there are no outgoing arcs x x x x x x B T E W G U D

54 A F C R S W D B E G T U W List L So we back up and look at the only unmarked arc from D. x x x x x x B T E W G U D x

55 A F C R S W D B E G T U W List L At this point, T gets added to the list. When the list is inspected, we note that it is in the list twice. Therefore a cycle exists. x x x x x x B T E W G U D T x

56 Deadlock Modeling process resource The resource has been assigned to the process. resource process The process is blocked, waiting for the resource. One way to model “units” of a resource is like this … This resource has 2 units that can be assigned.

57 Graph Reduction Given a directed resource graph 1.Find a process that is currently using a resource and not waiting for one. This process can be removed from the graph. This is because the process would eventually finish and its resources returns to the pool of available resources. 2. Find a process that’s only waiting for resource classes that aren’t fully allocated. This process isn’t contributing to deadlock since it will eventually get its resources and finish. Then its resources can be returned to the available pool. 3. Go back to step 1 until all possible connections have been removed. If there are any connections between processes and resources left When you are done, then the system will deadlock.

58 Deadlock Prevention Note that Deadlock prevention is different from detection.

59 1.Mutual exclusion condition : Each resource is either being used by exactly one process or it is available. 2. Hold and wait condition : Processes currently holding resources granted earlier can request additional new resources. 3.No preemption condition : Resources previously granted cannot be taken away from the process. The process must release them voluntarily. Once a process requests a resource that is not available, it cannot withdraw its request. 4.Circular wait condition: There must be a circular chain of two or more processes, each of which is waiting for a resource held by the next member of the chain. For deadlock to occur, all of the following conditions must hold. Deadlock prevention schemes all try to make sure that at least one of these conditions is not true.

60 Attacking the Mutual Exclusion Condition If no resource were ever assigned exclusively to a single process, then there would be no deadlock problems. Is this reasonable? How might you avoid mutual exclusion on a printer? It is difficult to avoid mutual exclusion. However, you can avoid assigning a resource unless and until it is absolutely necessary. Try to make sure that as few processes as possible can lay claim to the resource.

61 Attacking the Hold and Wait Condition 1.Require a process to request all of its resources when it is first created. This would be impossible for an interactive system. However, a batch system could do this … only add a job to the ready list when all of the resources it needs are available. But, is there a problem? Poor utilization of resources ! 2. Require a process to give up all resources it has allocated to it, before it can request any new ones. This is okay for interactive systems, but it forces a process to compete for all resources, even when it needs an incremental resource.

62 Attacking the No Preemption Condition This is not very promising … it is difficult to take a resource away from a process until the process has finished with it.

63 Attacking the Circular Wait Condition There are two possible approaches: Only allow a process to have one resource at a time. Provide a global numbering system for resources. A process may have as many resources as it wants, but requests must be in numerical order. For example, a process may request a printer and then a plotter, but never a plotter and then a printer!

64 Deadlock Avoidance Deadlock avoidance schemes control state transitions. They will only allow transitions due to allocations, when they can be certain that a deadlock cannot occur due to subsequent requests.

65 The Banker’s Algorithm The Banker’s algorithm was developed by Dijkstra in 1965 and provides a scheduling algorithm that can avoid deadlocks. It is modeled on the way a small town banker might deal with a group of customers to whom he has granted lines of credit. If granting a request leads to a safe state, the request is granted. If it does not, the request is denied. When a request is denied the customer may come back later to make the request again.

66 Dijkstra’s algorithm is elegant in concept, but is almost useless in practice. Why? 1.It requires a process to know in advance what its maximum resource needs will be. 2.It assumes that the number of available resources is constant so does not account for failures. 3.It assumes that the number of processes is constant so does not account for users logging in and out of a system.


Download ppt "DeadlocksDeadlocks CS 3060. Imagine a narrow set of stairs, only wide enough for one person to pass. However, the landings are big enough for several."

Similar presentations


Ads by Google