Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 3 Deadlocks -For MCA, PU

Similar presentations


Presentation on theme: "Chapter 3 Deadlocks -For MCA, PU"— Presentation transcript:

1 Chapter 3 Deadlocks -For MCA, PU www.forum.sheetal.com.np

2 Introduction and example
Situation in which two computer programs sharing the same resource are effectively preventing each other from accessing the resource, resulting in both programs ceasing to function. Occurs when a process or thread enters a waiting state because a resource requested is being held by another waiting process, which in turn is waiting for another resource held by another waiting process. Eg: - two process want to record a scanned doc in CD - Process A request Scanner, granted - Process B, programmed differently, request CD, granted - A asked CD, denied until B release - B asked scanner, denied until A release

3 3.1 Resources Any thing that must be acquired, used and released over the course of time Can be hardware resources or software resources Eg. CD, Scanner, database file, print server, network server etc…

4 3.1.1 Preemptable and Nonpreemptable Resources..1
Preemptable resources: that can be taken away from process without no ill effect Eg: Memory (can be swapped) Non-preemptable resources: that cann’t be taken away from its current process without no ill effect Eg:- CD In general deadlocks involves nonpreemptable resources

5 Preemptable and Nonpreemptable Resources (2)
Sequence of events required to use a resource: Request the resource. Use the resource. Release the resource. Request denied process will normally sit in tight loop requesting resources, then sleeping and then trying again As good as blocked because it cannot do any useful work

6 3.1.2 Resource Acquisition (1)
Figure 3-1. Using a semaphore to protect resources. (a) One resource. (b) Two resources.

7 Resource Acquisition (2)
Deadlock-free code.

8 Resource Acquisition (3)
Code with a potential deadlock.

9 3.2 Introduction To Deadlocks
Deadlock can be defined formally as follows: 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.

10 3.2.1 Conditions for Resource Deadlocks
Mutual exclusion condition Each resource is either currently to exactly one process or is available Hold and wait condition. Process currently holding resources that were granted earlier can request new resources No preemption condition. Resources previously granted cannot be forcibly taken away from process Circular wait condition. There must be a circular chain of two or more process, each of which is waiting for a resource held by the next member of chain

11 3.2.2 Deadlock Modeling (1) Directed graph is used to model deadlock
Two kind of nodes Square for resource Circle for process Directed arc from square to circle (resource to process) means resource has been previously requested and granted Directed arc from a process to a resources means that the process is currently blocked waiting for that resources A cycle in the graph means there is a deadlock

12 Deadlock Modeling (2) Resource allocation graphs. (a) Holding a resource. (b) Requesting a resource. (c) Deadlock.

13 Deadlock Modeling (3) Graph is called resource graph can be used for detection of deadlock Cycle in graph shows existence of deadlock Graph is called resource graph Ordering matters for deadlock a – c order no deadlock as no competition for resources d order carried out by graph e – j shows existence of cycle is graph hence dead lock OS can decide to grant particular resource avoiding deadlock Check the order k following its graph

14 An example of how deadlock occurs and how it can be avoided.
Deadlock Modeling (4) An example of how deadlock occurs and how it can be avoided.

15 An example of how deadlock occurs and how it can be avoided.
Deadlock Modeling (3) An example of how deadlock occurs and how it can be avoided.

16 An example of how deadlock occurs and how it can be avoided.
Deadlock Modeling (4) An example of how deadlock occurs and how it can be avoided.

17 Deadlock Modeling (5) Strategies for dealing with deadlocks:
Just ignore the problem. Detection and recovery. Let deadlocks occur, detect them, take action. Dynamic avoidance by careful resource allocation. Prevention, by structurally negating one of the four required conditions.

18 3.3 The Ostrich Algorithm Ostrich Algorithm: stick your head in the sand and pretend there is no problem (fun fact: nonsense folklore) Mathematicians: Unacceptable, anyhow at any cost deadlock should be prevented Engineer: How often problem is expected, if expected once is long duration better to ignore it rather than using heavy resources to prevent it

19 3.4.1 Deadlock Detection and Recovery (1)
Resource graph can be used for detection Draw resource graph for following 7 process (A – G) 6 resources (R-W) Process A holds R and wants S Process B holds nothing but wants T Process C holds nothing but wants S Process D holds U and wants S and T Process E holds T and wants V Process F holds W and wants S Process G holds V and wants U Is the process in deadlock? If so which process are involved

20 Deadlock Detection with One Resource of Each Type (2)
Figure 6-5. (a) A resource graph. (b) A cycle extracted from (a).

21 Deadlock Detection with One Resource of Each Type (3)
Algorithm for detecting deadlock: For each node, N in the graph, perform the following five steps with N as the starting node. Initialize L to the empty list, designate all arcs as unmarked. Add current node to end of L, check to see if node now appears in L two times. If it does, graph contains a cycle (listed in L), algorithm terminates. …

22 Deadlock Detection with One Resource of Each Type (3)
From given node, see if any unmarked outgoing arcs. If so, go to step 5; if not, go to step 6. Pick an unmarked outgoing arc at random and mark it. Then follow it to the new current node and go to step 3. If this is initial node, graph does not contain any cycles, algorithm terminates. Otherwise, dead end. Remove it, go back to previous node, make that one current node, go to step 3.

23 Deadlock Detection with One Resource of Each Type (3)
Lets take node as RABCSDTEFUVWG Start with R, initialize L as empty, add R to it giving L=[R,A] and Then [R,A,S] Dead end thus backtrack to R, completing inspection of R Start with A, stops quickly Start again with B, we continue upto D, resulting L=[B,T,E,V,G,U,D]. Make random choice. Picked S leads dead end, backtrack to D pick T update L=[B,T,E,V,G,U,D,T]. T repeated thus cycle and DEADLOCK

24 3.4.2 Deadlock Detection with Multiple Resources of Each Type (1)
Matrix and vector is maintained E is the existing resource vector E = (E1, E2, …..,Em) A is available resource vector A = (A1, A2, …..,Am) C is current allocation Matrix Cij is the number of instances of resource j that are held by process I R is Request Matrix Rij is the number of instances of the resources j that Pi wants

25 Deadlock Detection with Multiple Resources of Each Type (2)
Figure 6-6. The four data structures needed by the deadlock detection algorithm.

26 Deadlock Detection with Multiple Resources of Each Type (3)
Deadlock detection algorithm: Look for an unmarked process, Pi , for which the i-th row of R is less than or equal to A. If such a process is found, add the i-th row of C to A, mark the process, and go back to step 1. If no such process exists, the algorithm terminates.

27 Deadlock Detection with Multiple Resources of Each Type (4)
There are 4 tape drives, 2 plotters, 3 scanners and 1 CD-ROM. Three process hold and wants on following way P1 hold 1 scanner and wants 2 tape drive and 1 CD-ROM P2 holds 2 tape, 1 CD-ROM and wants 1 Tape and 1 Scanner P3 holds 1 Plotter, 2 Scanner and wants 2 Tape and 1 Plotter Is there DEADLOCK ?

28 Deadlock Detection with Multiple Resources of Each Type (3)
Figure 6-7. An example for the deadlock detection algorithm.

29 3.4.3 Recovery from Deadlock
Deadlock detected then what? Recovery (but not attractive) Recovery through preemption Recovery through rollback Recovery through killing processes

30 3.4.3.1 Recovery through preemption
If possible take temporarily take resources away from current owner and give it to another Manual intervention may be required especially in mainframe batch operating system

31 3.4.3.2 Recovery through rollback
If deadlock likely is known in prior, process checkpoint is periodically made Checkpointing means that process state, memory image, resource state is written in file so that it can be restarted latter New checkpoint shouldnot overwrite old one If deadlock detected rollbacked and resource assigned to one of deadlocked process Next process will wait till resource is free

32 3.4.3 Recovery through killing processes
Simplest way Just kill the process causing deadlock

33 3.5 Deadlock Avoidance We assumed processed ask for resources all at once in deadlock detection In fact in most of system resources are requested one at a time The system must to able to decide whether granting resources is safe or not? Algorithm exist to avoid deadlock by making right choice

34 3.5.1 Resource Trajectories
Trajectory definition: A trajectory or flight path is the path that a moving object follows through space as a function of time (Wikipedia) Abstraction for allocation of resources in graph Doesn’t translate directly into usable algorithm but gives a good intuitive feel for the nature of problem

35 Resource Trajectories (2)
Example: Two processes two resources The horizontal axis represent the number of instruction by process A The horizontal axis represent the number of instruction by process B At I1 A request a printer; I2 it needs plotter and released at I3 and I4 respectively Process B needs the plotter from I5 to I7 and printer from I6 to I8

36 Resource Trajectories (3)
Every point represents a joint state of two processes At p none the process executed any instruction Let scheduler choose to run A first; at point q some instruction of A executed but none of B At point q the trajectory become vertical indicating B is scheduled Single processor, path horizontal or vertical and always to north or east

37 Resource Trajectories (4)
Every point represents a joint state of two processes At p none the process executed any instruction Let scheduler choose to run A first; at point q some instruction of A executed but none of B At point q the trajectory become vertical indicating B is scheduled Single processor, path horizontal or vertical and always to north or east

38 Resource Trajectories (5)
When A cross I1 on the path from r to s, printer requested and granted When B reaches point t, it request the plotter The region slanting from southewest to northeast represents both process having printer (impossible) Similar for plotter If system ever enters the box bounded by I1 and I2 on the side and I5 and I6 top and bottom, it will eventually deadlock when it gets to the intersection of I2 and I6

39 Resource Trajectories (6)
At this point A is requesting the plotter and B is requesting the printer and both are already assigned Entire box is unsafe and must not be entered. At point t only safe thing to do is run process A until it gets to I4. System must decide whether it is safe to grant resource or not. To avoid deadlock B should be suspended until A has requested and released plotter

40 3.5.1 Resource Trajectories (7)
Two process resource trajectories.

41 3.5.2 Safe and Unsafe State (1)
A state is said to be safe if there is some scheduling order in which every process can run even if all of them suddenly request their maximum number of resources immediately 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.

42 Safe and Unsafe State (2)
Example (Single Resources 10 instances) Process A has 3 but may need 9 Process B has 2 but may need 4 Process C has 2 buy may need 7 Currently 3 resources free Fig a is in safe state ( Sequence B – C – A)

43 Safe and Unsafe States (2)
A has 3 but may need 9 eventually so the other Demonstration that the state in (a) is safe.

44 Safe and Unsafe States (3)
Demonstration that the state in (b) is not safe.

45 3.5.3 The Banker’s Algorithm
Data Structure Used Allocation Max Need Available Method: 1: Check Available >= Need if true grant resource release resource Update Available else goto 1 for next process

46 3.5.3.1 The Banker’s Algorithm for a Single Resource
Figure Three resource allocation states: (a) Safe. (b) Safe. (c) Unsafe.

47 3.5.3.2 The Banker’s Algorithm for Multiple Resources (1)
5 processes P0 through P4; 3 resource types: A (10 instances), B (5instances), and C (7 instances) Snapshot at time T0: Allocation Max Available A B C A B C A B C P P P P P

48 The Banker’s Algorithm for Multiple Resources (2)
The content of the matrix Need is defined to be Max – Allocation Need A B C P P P P P The system is in a safe state since the sequence < P1, P3, P4, P2, P0> satisfies safety criteria

49 The Banker’s Algorithm for Multiple Resources (3)
Safety Sequence = <P1, P3, P4, P0, P2>

50 The Banker’s Algorithm for Multiple Resources (4)
The banker’s algorithm with multiple resources.

51 The Banker’s Algorithm for Multiple Resources (2)
Algorithm for checking to see if a state is safe: Look for row, R, whose unmet resource needs all ≤ A. If no such row exists, system will eventually deadlock since no process can run to completion Assume process of row chosen requests all resources it needs and finishes. Mark process as terminated, add all its resources to the A vector. Repeat steps 1 and 2 until either all processes marked terminated (initial state was safe) or no process left whose resource needs can be met (there is a deadlock).

52 The Banker’s Algorithm - Disadvantage
It requires the number of processes to be fixed; no additional processes can start while it is executing. It requires that the number of resources remain fixed; no resource may go down for any reason without the possibility of deadlock occurring. It allows all requests to be granted in finite time, but one year is a finite amount of time. Similarly, all of the processes guarantee that the resources loaned to them will be repaid in a finite amount of time. While this prevents absolute starvation, some pretty hungry processes might develop. All processes must know and state their maximum resource need in advance

53 3.6.1 Deadlock Prevention Attacking the mutual exclusion condition
Attacking the hold and wait condition Attacking the no preemption condition Attacking the circular wait condition

54 3.6.1.1 Attacking the mutual exclusion condition
Attack mutual exclusion No resources were ever assigned exclusively to a single process – No deadlock Application depends on resource

55 3.6.1.2 Attacking the hold and wait condition
If we can prevent resource that hold from waiting for more resources we can eliminate deadlock Require all process to request all their resources before starting execution If one or more respoiurces are busy nothing would be allocated – process just wait Problem with this approach - Most of case max number of resources is not known before execution. If known bankers alogrith works fine - Resources will not be used optimally

56 3.6.1.2 Deadlock Prevention Attacking the mutual exclusion condition
Attacking the hold and wait condition Attacking the no preemption condition Attacking the circular wait condition

57 3.6.1 Attacking the no preemption condition

58 3.6.4 Attacking the Circular Wait Condition
Have a rule saying that a process is entitled only to a single resources at any moment. If it needs a second one release the first one Provide numbering of all resources

59 Approaches to Deadlock Prevention
Figure Summary of approaches to deadlock prevention.


Download ppt "Chapter 3 Deadlocks -For MCA, PU"

Similar presentations


Ads by Google