Chapter 6 Concurrency: Deadlock and Starvation I

Slides:



Advertisements
Similar presentations
Chapter 7: Deadlocks.
Advertisements

1 Concurrency: Deadlock and Starvation Chapter 6.
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.
ICS Principles of Operating Systems Lectures 8 and 9 - Deadlocks Prof. Dmitri V. Kalashnikov dvk ics.uci.edu Slides © Prof. Nalini Venkatasubramanian.
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.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Dave Bremer Otago Polytechnic,
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 81 Deadlock is:  A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set.  Example.
1 Concurrency: Deadlock and Starvation Chapter 6.
Chapter 6 Concurrency: Deadlock and Starvation
CSI 400/500 Operating Systems Spring 2009 Lecture #17 –Deadlocks Wednesday, April 15 th.
1 Wednesday, June 28, 2006 Command, n.: Statement presented by a human and accepted by a computer in such a manner as to make the human feel that he is.
Chapter 7: Deadlocks. 7.2 Chapter Objectives To develop a description of deadlocks, which prevent sets of concurrent processes from completing their tasks.
Deadlock CSCI 444/544 Operating Systems Fall 2008.
Concurrency: Deadlock & Starvation
The ‘deadlock’ conditions Reviewing some key points concerning the potential for ‘deadlock’ in an operating system.
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.
1 Concurrency: Deadlock and Starvation Chapter 6.
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.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 7: Deadlocks.
Chapter 6 Concurrency: Deadlock and Starvation
Deadlocks Gordon College Stephen Brinton. Deadlock Overview The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks.
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,
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Deadlocks.
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.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 7: Deadlocks Modified.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 7: Deadlocks.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Dave Bremer Otago Polytechnic,
Operating System Chapter 6. Concurrency: Deadlock and Starvation Lynn Choi School of Electrical Engineering.
Deadlock zDeadlock is a problem that can exist when a group of processes compete for access to fixed resources. zDefinition: deadlock exists among a set.
CS6502 Operating Systems - Dr. J. Garrido Deadlock – Part 2 (Lecture 7a) CS5002 Operating Systems Dr. Jose M. Garrido.
CIS Operating Systems Deadlock Professor Qiang Zeng Fall 2015.
Deadlock Operating Systems: Internals and Design Principles.
Deadlocks. What is a Deadlock “A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set.
Chapter 6 Concurrency: Deadlock and Starvation
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings.
Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill Technology Education Lecture 7 Operating Systems.
Chapter 8 Deadlocks. Objective System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection.
1 CS.217 Operating System By Ajarn..Sutapart Sappajak,METC,MSIT Chapter 6 Deadlocks Slide 1 Chapter 6 Deadlocks.
Informationsteknologi Monday, October 1, 2007Computer Systems/Operating Systems - Class 111 Today’s class Deadlock.
DEADLOCKS Prepared By: Dr. Vipul Vekariya. D EADLOCK A set of processes is deadlocked when each process in the set is blocked awaiting an event that can.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
Concurrency: Deadlock and Starvation
ITEC 202 Operating Systems
Chapter 12: Concurrency, Deadlock and Starvation
Deadlock B.Ramamurthy CSE421 9/17/2018 B.Ramamurthy.
Advanced Operating System Fall 2009
Chapter 7 Deadlock.
Deadlocks Session - 13.
DEADLOCK.
Operating System 6 CONCURRENCY: MUTUAL EXCLUSION AND SYNCHRONIZATION
Deadlock B.Ramamurthy CSE421 4/26/2019 B.Ramamurthy.
Deadlock B.Ramamurthy CS421 5/4/2019 B.Ramamurthy.
Presentation transcript:

Chapter 6 Concurrency: Deadlock and Starvation I Conditions for Deadlock Deadlock Prevention Deadlock Avoidance Banker’s Algorithm Deadlock Detection Strategies once Deadlock Detected Deadlock Detection Algorithm UNIX Concurrency Mechanisms

Deadlock Deadlock Deadlock can be defined as the permanent blocking of a set of processes that either compete for system resources or communicate with each other All deadlocks Involve conflicting needs for resources by two or more processes

Example of Deadlock (1) Process P Process Q ...... ...... Get A Get B ...... ...... Get A Get B Get B Get A Release A Release B Release B Release A

Progress of processes-Example of Deadlock (2) of Q 1 2 Release A P and Q want A A Required Release B Get A 3 deadlock inevitable P and Q want B B Required 5 Get B 4 6 Progress of P Get A Get B Release A Release B A Required B Required

Execution Paths -Example of Deadlock (3) 1. Q acquires B and then A, and then releases B and A. When P resumes execution, it will be able to acquire both resources. 2. Q acquires B and then A. P executes and blocks on a request for A. Q releases B and A. When P resumes execution, it will be able to acquire both resources. 5. P acquires A and then B. Q executes and blocks on a request for B. P releases A and B. When Q resumes execution, it will be able to acquire both resources. 6. P acquires A and then B, and then releases A and B. When Q resumes execution, it will be able to acquire both resources.

Deadlock Paths -Example of Deadlock (4) 3. Q acquires B and then P acquires A. Deadlock is inevitable, because as execution process Q will block on A and P will block on B. 4. P acquires A and then Q acquires B. Deadlock is inevitable, because as execution process Q will block on A and P will block on B.

Example of No Deadlock (1) Process P Process Q ...... ...... Get A Get B Release A Get A Get B Release B Release B Release A

Example of No Deadlock (2) Progress of Q 1 2 3 Release A 4 P and Q want A A Required Release B Get A P and Q want B B Required 5 Get B 6 Progress of P Get A Release A Get B Release B A Required B Required

Question 1 - Exercise/Home Work (1) For Figure of No Deadlock, provide a narrative description of each of the six depicted paths.

Reusable Resources A reusable resource is one that can be safely used by one process at a time and not depleted by that use Processes obtain resources that they later release for reuse by other processes Examples of reusable resources: processor time, I/O channels, main and secondary memory, files, databases, and semaphores Deadlock occurs if each process holds one resource and requests the other

Example of Deadlock Space is available for allocation of 200K bytes, and the following sequence of events occur Deadlock occurs if both processes progress to their second request P1 P2 . . . . . . Request 80K bytes; Request 70K bytes; . . . . . . Request 60K bytes; Request 80K bytes;

Consumable Resources A consumable resource is one that can be created (produced) and destroyed (consumed) by a process Examples of consumable resources: interrupts, signals, messages, and information in I/O buffers Deadlock may occur if a Receive message is blocking May take a rare combination of events to cause deadlock

Example of Deadlock Deadlock occurs if receive is blocking P1 is blocked for waiting message from P2 P2 is blocked for waiting message from P1 P1 P2 . . . . . . Receive(P2); Receive(P1); . . . . . . Send(P2); Send(P1);

Conditions for Deadlock Three conditions of policy must be present for a deadlock to be possible: Mutual exclusion only one process may use a resource at a time Hold-and-wait a process may hold allocated resources while awaiting assignment of others No preemption no resource can be forcibly removed from a process holding it

Conditions for Deadlock Circular wait a closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chain

Circular Wait Resource A Requests Held by Process P1 Process P2

Deadlock Prevention (1) Mutual Exclusion cannot be disallowed Hold-and-Wait The hold-and-wait condition can be prevented by: require that a process request all its required resources at one time block the process until all requests can be granted simultaneously process may be held up for a long time waiting for all its requests resources allocated to a process may remain unused for a long time. These resources could be used by other processes

Deadlock Prevention (2) No preemption This condition can be prevented in several ways: if a process is denied a further request, the process must release the original resources if a process cannot obtain a resource, the process may have to release its resources. Must have capability to restore to current state. This approach is practical only when the state can be easily saved and restored later, such as the processor.

Deadlock Prevention (3) Circular wait The circular-wait condition can be prevented by : define a linear ordering for resources once a resource R is obtained, then it may subsequently request only those resources of types following R in the ordering.

Deadlock Avoidance (1) Do not start a process if its demands might lead to deadlock Do not grant an incremental resource request to a process if this allocation might lead to deadlock

Deadlock Avoidance (2) Maximum resource requirement must be stated in advance Processes under consideration must be independent; no synchronization requirements There must be a fixed number of resources to allocate No process may exit while holding resources

Banker’s Algorithm - Deadlock Avoidance (1) Total amount of each resource in the system Resource = ( R1, R2, ......, Rm ) Total amount of each resource not allocated to a process Available = ( V1, V2, ......, Vm )

Banker’s Algorithm - Deadlock Avoidance (2) Requirement of each process for each resource C11 C12 ...... C1m Claim = C21 C22 ...... C2m .......................... Cki: process k Cn1 Cn2 ...... Cnm for resource j Current allocation A11 A12 ...... A1m Allocation = A21 A22 ...... A2m .......................... Aki: process k An1 An2 ...... Anm for resource j

Relationships - Banker’s Algorithm (3) Ri = Vi + S Aki, for all i: All resources are k=1 either available or allocated. Cki <= Ri, for all k, i: No process can claim more than the total amount of resources in the system. Aki <= Cki, for all k, i: No process is allocated more resources of any type than the process originally claimed to need.

Deadlock Avoidance Policy - Banker’s Algorithm (4) Ri >= C(n+1)i + Sum Cki, for all i k=1 A new process Pn+1 is only started if the maximum claim of all current processes plus those of the new process can be met.

Safe State -Banker’s Algorithm (5) The state of the system is simply the current allocation of resources to processes. Thus the state consists of the two vectors, Resource and Available, and two matrices, Claim and Allocation. Safe State A safe state is a state in which there is at least one sequence in which all of the processes can be run to completion that does not result in a deadlock.

Determination of a Safe State-Banker’s Algorithm (6) R1 R2 R3 R1 R2 R3 R1 R2 R3 P1 3 2 2 P1 1 0 0 9 3 6 P2 6 1 3 P2 6 1 2 Resource Vector P3 3 1 4 P3 2 1 1 P4 4 2 2 P4 0 0 2 R1 R2 R3 0 1 1 Claim Matrix Allocation Matrix Available Vector (a) Initial State - A Safe State?

Determination of a Safe State-Banker’s Algorithm (7) R1 R2 R3 R1 R2 R3 R1 R2 R3 P1 3 2 2 P1 1 0 0 9 3 6 P2 0 0 0 P2 0 0 0 Resource Vector P3 3 1 4 P3 2 1 1 P4 4 2 2 P4 0 0 2 R1 R2 R3 6 2 3 Claim Matrix Allocation Matrix Available Vector (b) P2 Runs to Completion

Determination of a Safe State-Banker’s Algorithm (8) R1 R2 R3 R1 R2 R3 R1 R2 R3 P1 0 0 0 P1 0 0 0 9 3 6 P2 0 0 0 P2 0 0 0 Resource Vector P3 3 1 4 P3 2 1 1 P4 4 2 2 P4 0 0 2 R1 R2 R3 7 2 3 Claim Matrix Allocation Matrix Available Vector (c) P1 Runs to Completion

Determination of a Safe State-Banker’s Algorithm (9) R1 R2 R3 R1 R2 R3 R1 R2 R3 P1 0 0 0 P1 0 0 0 9 3 6 P2 0 0 0 P2 0 0 0 Resource Vector P3 3 1 4 P3 2 1 1 P4 4 2 2 P4 0 0 2 R1 R2 R3 9 3 4 Claim Matrix Allocation Matrix Available Vector (d) P3 Runs to Completion

Banker’s Algorithm - Deadlock Avoidance (10) ..... while ((possible) and (rest != null)) do find a Pk in rest such that claim[k, *] - allocation[K, *] <= currentavail; if found then currentavail:=currentavail + allocation[K, *]; rest:= rest - {Pk} else possible:=false end end; ......

Determination of an Unsafe State-Banker’s Algorithm (11) R1 R2 R3 R1 R2 R3 R1 R2 R3 P1 3 2 2 P1 1 0 0 9 3 6 P2 6 1 3 P2 5 1 1 Resource Vector P3 3 1 4 P3 2 1 1 P4 4 2 2 P4 0 0 2 R1 R2 R3 1 1 2 Claim Matrix Allocation Matrix Available Vector (a) Initial State - A Safe State?

Determination of an Unsafe State-Banker’s Algorithm (12) R1 R2 R3 R1 R2 R3 R1 R2 R3 P1 3 2 2 P1 2 0 1 9 3 6 P2 6 1 3 P2 5 1 1 Resource Vector P3 3 1 4 P3 2 1 1 P4 4 2 2 P4 0 0 2 R1 R2 R3 0 1 1 Claim Matrix Allocation Matrix Available Vector (b) P1 Requests One unit each of R1 and R3 - An Unsafe State

Question 2 - Exercise/Home Work (1) R1 R2 R3 R4 R1 R2 R3 R4 R1 R2 R3 R4 P1 0 0 1 2 0 0 1 2 P2 2 7 5 0 2 0 0 0 P3 6 6 5 6 0 0 3 4 P4 4 3 5 6 2 3 5 4 P5 0 6 5 2 0 3 3 2 Claim Matrix Allocation Matrix Still Needs 6 7 12 12 2 1 0 0 Resource Vector Available Vector

Question 2- Exercise/Home Work (2) Consider the system given: a. Compute what each process still might request and display in the columns labeled “still needs.” b. Is this system currently in a safe or unsafe state? Why? c. Is this system currently deadlocked? Why or Why not? d. Which processes, if any, are or may become deadlocked? e. If a request from P3 arrives for (0, 1, 3, 4), can that request to be safely granted immediately? In what state (deadlocked, safe, unsafe) would immediately granting that whole request leave the system? Which processes, if any, are or may become deadlocked if this whole request is granted immediately?