IT 344: Operating Systems Module 8 Deadlock Chia-Chi Teng CTB 265.

Slides:



Advertisements
Similar presentations
Concurrency: Deadlock and Starvation Chapter 6. Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate.
Advertisements

Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
6. Deadlocks 6.1 Deadlocks with Reusable and Consumable Resources
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
Avishai Wool lecture Introduction to Systems Programming Lecture 5 Deadlocks.
Deadlock Chapter 3 R1 R2 P2P1 Allocated Requested.
Multi-Object Synchronization. Main Points Problems with synchronizing multiple objects Definition of deadlock – Circular waiting for resources Conditions.
Deadlock CSCI 444/544 Operating Systems Fall 2008.
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
1 Concurrency: Deadlock and Starvation Chapter 6.
CSE 451: Operating Systems Winter 2011 Deadlock Mark Zbikowski Gary Kimura.
CSE 451: Operating Systems Spring 2013 Module 9 Deadlock Ed Lazowska Allen Center 570 © 2013 Gribble, Lazowska, Levy, Zahorjan.
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.
IT 344: Operating Systems Winter 2010 Module 8 Deadlock Chia-Chi Teng CTB 265.
1 Processes, Threads, Race Conditions & Deadlocks Operating Systems Review.
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.
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 7: Deadlocks.
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance 3.6. Deadlock prevention.
1 Deadlocks 2 Resources Examples of computer resources –printers –tape drives –tables Processes need access to resources in reasonable order Suppose.
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
1 Deadlocks Chapter 3. 2 Resources Examples of computer resources –printers –tape drives –tables Processes need access to resources in reasonable order.
Operating Systems 软件学院 高海昌 Operating Systems Gao Haichang, Software School, Xidian University 22 Contents  1. Introduction** 
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
MODERN OPERATING SYSTEMS Third Edition ANDREW S. TANENBAUM Chapter 6 Deadlocks Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All.
1 Deadlock. 2 Concurrency Issues Past lectures:  Problem: Safely coordinate access to shared resource  Solutions:  Use semaphores, monitors, locks,
CS333 Intro to Operating Systems Jonathan Walpole.
Operating Systems COMP 4850/CISG 5550 Deadlocks Dr. James Money.
Copyright ©: Nahrstedt, Angrave, Abdelzaher1 Deadlock.
ICS Deadlocks 6.1 Deadlocks with Reusable and Consumable Resources 6.2 Approaches to the Deadlock Problem 6.3 A System Model –Resource Graphs –State.
CSE 451: Operating Systems Spring 2010 Module 9 Deadlock John Zahorjan Allen Center 534.
Sistem Operasi IKH311 Deadlock. 2 Resources Examples of computer resources printers tape drives tables Processes need access to resources in reasonable.
Deadlocks Lots of resources can only be used by one process at a time. Exclusive access is needed. Suppose process A needs R1 + R2 and B needs R1 + R2.
Deadlock CSE451 Andrew Whitaker. Review: What Can Go Wrong With Threads? Safety hazards  “Program does the wrong thing” Liveness hazards  “Program never.
Process Management Deadlocks.
CSE 120 Principles of Operating
Concurrency: Deadlock and Starvation
CSE 451: Operating Systems Winter 2014 Module 9 Deadlock
CSE 451: Operating Systems Winter 2012 Deadlock
Deadlock Management.
CS703 - Advanced Operating Systems
CSE451 Basic Synchronization Spring 2001
Chapter 7: Deadlocks Source & Copyright: Operating System Concepts, Silberschatz, Galvin and Gagne.
Chapter 6 : Deadlocks What is a Deadlock?
Introduction to Operating Systems
Deadlock, Illustrated.
CSE 451: Operating Systems Winter 2007 Module 8 Deadlock
CSE 451: Operating Systems Spring 2006 Module 8 Deadlock
Synchronization Hank Levy 1.
CS 333 Introduction to Operating Systems Class 7 - Deadlock
DPNM Lab. Dept. of CSE, POSTECH
CSE 451: Operating Systems Autumn 2009 Module 9 Deadlock
CSE 451: Operating Systems Spring 2005 Module 8 Deadlock
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
CSE 451: Operating Systems Autumn 2010 Module 9 Deadlock
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
CSE 451: Operating Systems Winter 2007 Module 8 Deadlock
SE350: Operating Systems Lecture 5: Deadlock.
OPERATING SYSTEMS DEADLOCKS.
Chapter 7: Synchronization Examples
CSE 451: Operating Systems Spring 2008 Module 9 Deadlock
Introduction to Deadlocks
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
CSE 451: Operating Systems Winter 2004 Module 8 Deadlock
CSE 153 Design of Operating Systems Winter 2019
CSE 451: Operating Systems Winter 2006 Module 8 Deadlock
Deadlock CSE 2431: Introduction to Operating Systems
Presentation transcript:

IT 344: Operating Systems Module 8 Deadlock Chia-Chi Teng CTB 265

Administrivia This week’s HW –Read web server scheduling paper & write up Reading –Chap 5 Processes and Threads –Chap 6 Synchronization –Chap 7 Scheduling –Chap 8 Deadlock Project #1 –Proposal pass off due next Tuesday, during lab time –Presentation and project pass off due Oct 16, during lab time 7/7/20162

3 Bounded buffer using semaphores (both binary and counting) Note 1: I have elided all the code concerning which is the first full buffer, which is the last full buffer, etc. Note 2: Try to figure out how to do this without using counting semaphores! var mutex: semaphore = 1 ;mutual exclusion to shared data empty: semaphore = n ;count of empty buffers (all empty to start) full: semaphore = 0 ;count of full buffers (none full to start) producer: wait(empty); one fewer buffer, block if none available wait(mutex); get access to pointers signal(mutex) ; done with pointers signal(full) ; note one more full buffer consumer: wait(full) ;wait until there’s a full buffer wait(mutex) ;get access to pointers signal(mutex) ; done with pointers signal(empty) ; note there’s an empty buffer

7/7/20164

5 Definition A thread is deadlocked when it’s waiting for an event that can never occur –I’m waiting for you to clear the intersection, so I can proceed but you can’t move until he moves, and he can’t move until she moves, and she can’t move until I move –thread A is in critical section 1, waiting for access to critical section 2; thread B is in critical section 2, waiting for access to critical section 1 –I’m trying to book a vacation package to Tahiti – air transportation, ground transportation, hotel, side-trips. It’s all-or-nothing – one high-level transaction – with the four databases locked in that order. You’re trying to do the same thing in the opposite order.

7/7/20166 Requirements 1.Mutual Exclusion 2.Hold and Wait 3.No Preemption 4.Circular Wait

7/7/20167 Resource graph A deadlock exists if there is an irreducible cycle in the resource graph (such as the one above)

7/7/20168 Graph reduction A graph can be reduced by a thread if all of that thread’s requests can be granted –in this case, the thread eventually will terminate – all resources are freed – all arcs (allocations) to it in the graph are deleted Miscellaneous theorems (Holt, Havender): –There are no deadlocked threads iff the graph is completely reducible –The order of reductions is irrelevant (Detail: resources with multiple units)

7/7/20169 Resource allocation graph with no cycle Silberschatz, Galvin and Gagne  2002 What would cause a deadlock?

7/7/ Resource allocation graph with a deadlock Silberschatz, Galvin and Gagne  2002

7/7/2016 © 2007 Gribble, Lazowska, Levy, Zahorjan 11 Resource allocation graph with a cycle but no deadlock Silberschatz, Galvin and Gagne  2002

7/7/ Approaches to Deadlock Break one of the four required conditions –Mutual Exclusion? –Hold and Wait? –No Preemption? –Circular Wait? Broadly classified as: –Prevention (static), or –Avoidance (dynamic), or –detection (and recovery)

7/7/ Prevention (static) Mutual exclusion: in general cannot be disallowed Hold and Wait each thread obtains all resources at the beginning; blocks until all are available drawback? Circular Wait resources are numbered; each thread obtains them in sequence (which means acquiring some before they are actually needed) why does this work? pros and cons?

7/7/ Avoidance (dynamic) Allow three necessary conditions but prevent circular wait Circular Wait –each thread states its maximum claim for every resource type –system runs the Banker’s Algorithm at each allocation request Banker  incredibly conservative if I were to allocate you that resource, and then everyone were to request their maximum claim for every resource, could I find a way to allocate remaining resources so that everyone finished? –More on this in a moment…

7/7/ every once in a while, check to see if there’s a deadlock –how? if so, eliminate it –how? Detection and recovery

7/7/ Avoidance: Banker’s Algorithm example When a request is made –pretend you granted it –pretend all other legal requests were made –can the graph be reduced? if so, allocate the requested resource if not, block the thread

7/7/ PotsPans MeYou Max: 1 pot 2 pans Max: 2 pots 1 pan 1. I request a pot

7/7/ PotsPans MeYou Max: 1 pot 2 pans Max: 2 pots 1 pan Allocation is OK; there is a way for me to complete, and then you can complete

7/7/ PotsPans MeYou Max: 1 pot 2 pans Max: 2 pots 1 pan 2. You request a pot

7/7/ PotsPans MeYou Max: 1 pot 2 pans Max: 2 pots 1 pan Allocation is OK; there is a way for me to complete, and then you can complete

7/7/ PotsPans MeYou Max: 1 pot 2 pans Max: 2 pots 1 pan 3a. You request a pan

7/7/ PotsPans MeYou Max: 1 pot 2 pans Max: 2 pots 1 pan NO! Both of us might be unable to complete!

7/7/ PotsPans MeYou Max: 1 pot 2 pans Max: 2 pots 1 pan 3b. I request a pan

7/7/ PotsPans MeYou Max: 1 pot 2 pans Max: 2 pots 1 pan Allocation is OK; there is a way for me to complete, and then you can complete

7/7/ Current practice Microsoft SQL Server –“The SQL Server Database Engine automatically detects deadlock cycles within SQL Server. The Database Engine chooses one of the sessions as a deadlock victim and the current transaction is terminated with an error to break the deadlock.” Oracle –As Microsoft SQL Server, plus “Multitable deadlocks can usually be avoided if transactions accessing the same tables lock those tables in the same order... For example, all application developers might follow the rule that when both a master and detail table are updated, the master table is locked first and then the detail table.”

ASP.NET (or other Web server technologies) –Thread pool management –Do not block thread on the pool that is waiting for another function on the pool –Don’t wait (indefinitely) for async functions –How to detect? –How to fix? 7/7/ class ConnectionSocket { public void Connect() { IPHostEntry ipHostEntry = Dns.Resolve(Dns.GetHostName()); IPEndPoint ipEndPoint = new IPEndPoint(ipHostEntry.AddressList[0], 80); Socket s = new Socket(ipEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp); IAsyncResult ar = s.BeginConnect(ipEndPoint, null, null); s.EndConnect(ar); }

7/7/ Windows internals (Linux no different) –“The (Windows) NT kernel architecture is a deadlock minefield. With the multi-threaded re-entrant kernel there is plenty of deadlock potential.” –“Lock ordering is great in theory, and NT was originally designed with mutex levels, but they had to be abandoned. Inside the NT kernel there is a lot of interaction between memory management, the cache manager, and the file systems, and plenty of situations where memory management (maybe under the guise of its modified page writer) acquires its lock and then calls the cache manager. This happens while the file system calls the cache manager to fill the cache which in turn goes through the memory manager to fault in its page. And the list goes on.”

7/7/ Summary Deadlock is real! Deadlock is bad! Not unique to operating systems, e.g. database We can deal with it either statically (prevention) or dynamically (avoidance and detection) In practice, you’ll encounter lock ordering, periodic deadlock detection/correction, and minefields