Deadlock B.Ramamurthy CSE421 4/26/2019 B.Ramamurthy.

Slides:



Advertisements
Similar presentations
1 Concurrency: Deadlock and Starvation Chapter 6.
Advertisements

1 Concurrency: Deadlock and Starvation Chapter 6.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
1 Concurrency: Deadlock and Starvation Chapter 6.
Concurrency: Deadlock and Starvation Chapter 6. Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate.
Lecture 6 :Deadlocks. Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate with each other Involves.
Concurrency: Deadlock and Starvation Chapter 6. Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
Concurrency: Deadlock and Starvation Chapter 6. Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate.
Chapter 6 Concurrency: Deadlock and Starvation
Chapter 6 Concurrency: Deadlock and Starvation
Chapter 6 Concurrency: Deadlock and Starvation I
5/25/2015Page 1 Deadlock Management B. Ramamurthy.
Concurrency: Deadlock & Starvation
CS 450 OPERATING SYSTEMS DEADLOCKS Manju Muralidharan Priya.
1 Lecture 8: Deadlocks Operating System Spring 2008.
1 M. Bozyigit ICS Operating Systems Deadlock. 2 Deadlock n Permanent blocking of a set of processes that either compete for system resources or communicate.
OS Spring 2004 Concurrency: Principles of Deadlock Operating Systems Spring 2004.
Witawas Srisa-an Chapter 6
CPSC 4650 Operating Systems Chapter 6 Deadlock and Starvation
OS Fall’02 Concurrency: Principles of Deadlock Operating Systems Fall 2002.
1 Concurrency: Deadlock and Starvation Chapter 6.
Chapter 6 Concurrency: Deadlock and Starvation
Concurrency: Deadlock and Starvation Chapter 6. Goal and approach Deadlock and starvation Underlying principles Solutions? –Prevention –Detection –Avoidance.
1 Concurrency: Deadlock and Starvation Chapter 6.
Concurrency: Deadlock and Starvation
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Dave Bremer Otago Polytechnic,
1 Announcements The fixing the bug part of Lab 4’s assignment 2 is now considered extra credit. Comments for the code should be on the parts you wrote.
Operating System Chapter 6. Concurrency: Deadlock and Starvation Lynn Choi School of Electrical Engineering.
CIS Operating Systems Deadlock Professor Qiang Zeng Fall 2015.
Deadlock Operating Systems: Internals and Design Principles.
Chapter 7 Deadlocks. 7.1 Introduction Deadlock Common approaches to deal with deadlock – Prevention – Avoidance – Detection and recovery.
Chapter 6 Concurrency: Deadlock and Starvation
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings.
Chapter 8 Deadlocks. Objective System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection.
Copyright ©: Nahrstedt, Angrave, Abdelzaher1 Deadlock.
Informationsteknologi Monday, October 1, 2007Computer Systems/Operating Systems - Class 111 Today’s class Deadlock.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
Chapter 7: Deadlocks.
Process Management Deadlocks.
Chapter 7: Deadlocks.
Concurrency: Deadlock and Starvation
Deadlock Management.
ITEC 202 Operating Systems
G.Anuradha Ref:- Galvin
Deadlock B.Ramamurthy CSE421 9/17/2018 B.Ramamurthy.
Chapter 7: Deadlocks.
Advanced Operating System Fall 2009
Operating System: DEADLOCKS
Chapter 7 Deadlock.
Process Deadlocks.
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
Deadlock B.Ramamurthy CSE421 1/11/2019 B.Ramamurthy.
G.Anuradha Ref:- Galvin
Chapter 7: Deadlocks.
Deadlock B.Ramamurthy CSE421 2/23/2019 B.Ramamurthy.
DEADLOCK.
Deadlock B.Ramamurthy CSE421 4/23/2019 B.Ramamurthy.
Operating System 6 CONCURRENCY: MUTUAL EXCLUSION AND SYNCHRONIZATION
Deadlock B.Ramamurthy CSE421 5/1/2019 B.Ramamurthy.
Deadlock B.Ramamurthy CS421 5/4/2019 B.Ramamurthy.
Chapter 7: Deadlocks.
CSE 542: Operating Systems
Deadlock B.Ramamurthy CSE421 8/28/2019 B.Ramamurthy.
Deadlock B.Ramamurthy CSE421 9/3/2019 B.Ramamurthy.
Deadlock CSE 2431: Introduction to Operating Systems
Presentation transcript:

Deadlock B.Ramamurthy CSE421 4/26/2019 B.Ramamurthy

Introduction Parallel operation among many devices driven by concurrent processes contribute significantly to high performance. But concurrency also results in contention for resources and possibility of deadlock among the vying processes. Deadlock is a situation where a group of processes are permanently blocked waiting for the resources held by each other in the group. Typical application where deadlock is a serious problem: Operating system, data base accesses, and distributed processing. 4/26/2019 B.Ramamurthy

Topics for discussion Types of resources Conditions for deadlock Deadlock prevention Deadlock detection Deadlock avoidance Dining philosophers problem 4/26/2019 B.Ramamurthy

Types of resources Two general categories of resources: reusable and consumable. Reusable resource: One that can be safely used by one process at a time and not depleted by the use. Later it can be used by some other process. Examples: processors, IOU channels, main and secondary memory, devices, files, databases, semaphores, locks. Consumable resource: One that can be produced and consumed (destroyed). Examples: interrupts, signals, messages, information in IO buffers. 4/26/2019 B.Ramamurthy

Conditions for a deadlock Four preconditions that must be present for a deadlock to occur: Mutual exclusion: Only one process can use a resource at a time. Hold and wait: A process must hold the resources while awaiting assignment of other resources. No preemption: No resource can be forcibly removed from a process holding it. Circular wait: A closed chain of processes exists, such that each process holds at least one resources needed by the next process in the chain. 4/26/2019 B.Ramamurthy

General design policy What is your policy? Spend resources, effort and time during normal operation to prevent deadlock from occurring ? (pessimistic and conservative) or Incur low overhead during normal deadlock-free operation without worrying about deadlock. Take care of resolving it when and if it happens? (optimistic). In this case, recovery from deadlock may be expensive. Detect deadlock and recover. Optimal solution? between cost of recovery and cost of prevention. 4/26/2019 B.Ramamurthy

Deadlock prevention To design a system in such a way that the possibility of a deadlock is excluded a priori. Prevention philosophy: We know what the preconditions are; So prevent one or more these from occurring. For example: Circular wait can be prevented by linear ordering of the resource types. If a process holds resources of type Rj , then it can request resources of type Rk, k > j, but not Ri where i <= j. Similarly, any other process holding Ri can request Rj but a process holding Rj cannot request Ri. 4/26/2019 B.Ramamurthy

Deadlock detection All the resource requests by processes are granted as long as they within the availability limits. Periodically the OS checks for circular wait and resolves it. Policy1: When to check for circular wait? Every time a resource request is made? For every “n-th” request? Policy2: How to break the deadlock once detected? Question: What is a policy ? and What is a mechanism? Ans: “WHAT to do” and “HOW to do” describe policy and mechanism respectively. 4/26/2019 B.Ramamurthy

How to break a deadlock? Soln1: Abort all deadlocked processes and reclaim resources. Soln2: Back up all the deadlock processes to a predefined checkpoint and restart. Soln3: Gradually abort processes in deadlock one by one until deadlock is resolved. Soln4: Successively preempt resources until deadlock is cleared. 4/26/2019 B.Ramamurthy

Scope of various policies Total deadlock prevention leads to inefficient use of resources and inefficient execution of processes. DETECTION Definite deadlock UNSAFE Deadlock possible but no deadlock SAFE No Deadlock possible PREVENTION AVOIDANCE 4/26/2019 B.Ramamurthy

Deadlock avoidance Deadlock avoidance requires some future knowledge of requests for resources from each of the participating processes. Policies for avoidance: (what to do?) Do not start a process if its demands might lead to a deadlock. Do not grant an incremental resource request to a process if this allocation might lead to a deadlock. 4/26/2019 B.Ramamurthy

Deadlock avoidance mechanism (How to do it?) Data structures Algorithms : Resource allocation algorithm Testing for safety algorithm (Banker’s algorithm) Assume n processes, m different types of resources. 4/26/2019 B.Ramamurthy

Deadlock avoidance - Data structures Resource vector: [R1....Rm] : Total number of resource in the system. Resource[1] is R1, tells that there R1 units of resource type 1. Available vector : [AV1....AVm] : Currently available. Available[1] is AV1 tells that there are AV1 units of resource 1 available. Claim matrix : [C1*....Cn*] where each is vector of m elements: Maximum requirement for each process. Claim is a nXm matrix defines the maximum of resources demanded by each process. Allocation matrix : [A1*...An*] current allocation for each process. It is an nXm matrix . 4/26/2019 B.Ramamurthy

... avoidance - Resource allocation If Request[*] > Available[*] suspend process; else define newstate by: 1) Allocation[i,*] = Allocation[i,*]+ Request[*] 2) Available[*] = Available[*] - Request[*] If safe (newstate) then go ahead with allocation; else restore original state and suspend process. 4/26/2019 B.Ramamurthy

Safety algorithm - bool safe(state); CurrentAvail = Available; Rest = {set of all processes}; Possible = True; while (Possible) && (Rest not Empty) Find Pk in Rest such that Claim[k,*] - Allocation[k,*] < CurrentAvail; if found, { CurrentAvail = CurrentAvail + Allocation[k,*]; Rest = Rest - {Pk};} else Possible = False; /* ASSERT: either Rest is empty or Allocation failed */ safe = (Rest is empty); 4/26/2019 B.Ramamurthy

Example : bool safe(state); P1 P2 P3 P4 P1 P2 P3 P4 R1 3 6 3 4 1 6 2 0 R2 2 1 1 2 0 1 1 0 R3 2 3 4 2 0 2 1 2 CLAIM MATRIX ALLOCATION MATRIX R1 2 0 1 4 R2 2 0 0 2 R3 2 1 3 0 NEED MATRIX = CLAIM --- ALLOCATION 4/26/2019 B.Ramamurthy

Example (contd.) With the state of the system as given above and the current availability as given by AVAIL [R1 R2 R3 ] = 0 1 1, can you find a sequence of processor execution that will result in a safe state (no deadlock state)? Some form of serializability. Quite common in data base applications. Is the given state safe? YES. (means you have safe sequence) What is the safe sequence? {P2, P1, P3, P4} 4/26/2019 B.Ramamurthy

Example (contd.) In other words, in the current state P2 can run with AVAIL, P1 can go after completion of P2 with the reclaimed resources from P2+AVAIL, next P3 can go with available resources from {P2,P1}+AVAIL, and finally P4 with resources from {P2,P1,P3}+AVAIL. Next we will look at an example that illustrates complete allocation scheme “avoids” deadlock by making use of this safety algorithm discussed above. 4/26/2019 B.Ramamurthy

Current state - AVAIL [1 1 2] P1 P2 P3 P4 P1 P2 P3 P4 R1 3 6 3 4 1 5 2 0 R2 2 1 1 2 0 1 1 0 R3 2 3 4 2 0 1 1 2 CLAIM MATRIX ALLOCATION MATRIX Request of [1 0 1] by P2 can be safely allocated. Proof: Above example. But the same request from P1 at this state given above is unsafe. So cannot be allocated. 4/26/2019 B.Ramamurthy

Dining philosopher problem Classic problem is usually discussed with 5 philosophers: But you should really consider N philosophers. 5 philosophers, 5 plates of noodles, 5 forks and circular dining table. Each one needs two forks. Examine how it satisfies the preconditions for deadlock! Mutual exclusion : shared fork. Hold and wait: One may hold the left fork and wait forever for the right fork. No preemption: One may not want to give up the fork he/she has. Circular wait: Of course, one waiting on the other around the table. 4/26/2019 B.Ramamurthy

Monitor solution See the enclosed solution for DP problem using monitors. Can you define a general base class DP that can used to solve any problem that can be modeled as DP? use Posix/Solaris condition variables and mutex for condition and suspension requirements of the monitor. 4/26/2019 B.Ramamurthy

Summary In general deadlock handling is left to the application level. But this situation may change with proliferation of database and multimedia applications. We need built-in mechanisms. We looked at some of them. Prevention is conservative, detection and resolution is too optimistic, avoidance attempts to provide a satisfactory solution for some restricted classes of applications. 4/26/2019 B.Ramamurthy