CS 162 Discussion Section Week 4. Administrivia Design reviews Friday, Monday and Tuesday – Every member must attend – Will test that every member understands.

Slides:



Advertisements
Similar presentations
Chapter 7: Deadlocks.
Advertisements

Operating Systems Semaphores II
Deadlock and Starvation
Concurrency: Deadlock and Starvation Chapter 6. Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate.
Operating Systems Lecture Notes Deadlocks Matthew Dailey Some material © Silberschatz, Galvin, and Gagne, 2002.
Chapter 7: Deadlocks.
CS 162 Discussion Section Week 4 9/ /4. Today’s Section ●Project administrivia ●Quiz ●Lecture Review ●Worksheet and Discussion.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 7: Deadlocks.
Tanenbaum Ch 6 Silberschatz Ch 7
CS162 Operating Systems and Systems Programming Lecture 9 Deadlock September 28, 2005 Prof. John Kubiatowicz
CS 162 Week 3 Discussion (2/13 – 2/14). Today’s Section Project Administrivia (5 min) Quiz (5 min) Review Lectures 6 and 7 (15 min) Worksheet and Discussion.
Deadlocks CS 3100 Deadlocks1. The Deadlock Problem A set of blocked processes each holding a resource and waiting to acquire a resource held by another.
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.
CS162 Operating Systems and Systems Programming Lecture 9 Tips for Working in a Project Team/ Cooperating Processes and Deadlock September 27, 2006 Prof.
Deadlocks. 2 System Model There are non-shared computer resources –Maybe more than one instance –Printers, Semaphores, Tape drives, CPU Processes need.
Chapter 7: Deadlocks. 7.2 Chapter Objectives To develop a description of deadlocks, which prevent sets of concurrent processes from completing their tasks.
1 Chapter 7: Deadlock. 2 The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance.
Deadlock CSCI 444/544 Operating Systems Fall 2008.
CS444/CS544 Operating Systems Synchronization 2/21/2007 Prof. Searleman
CS162 Operating Systems and Systems Programming Lecture 9 Tips for Working in a Project Team/ Cooperating Processes and Deadlock September 26, 2007 Prof.
02/19/2008CSCI 315 Operating Systems Design1 Deadlock Notice: The slides for this lecture have been largely based on those accompanying the textbook Operating.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 7: Deadlocks.
Deadlocks Gordon College Stephen Brinton. Deadlock Overview The Deadlock Problem System Model Deadlock Characterization Methods for Handling Deadlocks.
1 School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Ch 7: Deadlock Dr. Mohamed Hefeeda.
What we will cover…  The Deadlock Problem  System Model  Deadlock Characterization  Methods for Handling Deadlocks  Deadlock Prevention  Deadlock.
CS162 Operating Systems and Systems Programming Lecture 9 Tips for Working in a Project Team/ Cooperating Processes and Deadlock February 16, 2010 Ion.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Deadlocks.
CSC139 Operating Systems Lecture 9 Deadlock Adapted from Prof. John Kubiatowicz's lecture notes for CS162 Copyright.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Cosc 4740 Chapter 6, Part 4 Deadlocks. The Deadlock Problem A set of blocked processes each holding a resource and waiting to acquire a resource held.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-6 Deadlocks Department of Computer Science and Software Engineering.
Deadlocks Silberschatz Ch. 7 and Priority Inversion Problems.
CS6502 Operating Systems - Dr. J. Garrido Deadlock – Part 2 (Lecture 7a) CS5002 Operating Systems Dr. Jose M. Garrido.
Chapter 7: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock.
 The Deadlock Problem  System Model  Deadlock Characterization  Methods for Handling Deadlocks  Deadlock Prevention  Deadlock Avoidance  Deadlock.
COSC 3407: Operating Systems Lecture 9: Readers-Writers and Language Support for Synchronization.
Deadlocks System Model RAG Deadlock Characterization
CS333 Intro to Operating Systems Jonathan Walpole.
Operating Systems COMP 4850/CISG 5550 Deadlocks Dr. James Money.
CS162 Operating Systems and Systems Programming Lecture 9 Tips for Working in a Project Team/ Cooperating Processes and Deadlock September 26, 2008 Prof.
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.
Chapter 7: Deadlocks. 7.2CSCI 380 – Operating Systems Chapter 7: Deadlocks The Deadlock Problem System Model Deadlock Characterization Methods for Handling.
CS307 Operating Systems Deadlocks Fan Wu Department of Computer Science and Engineering Shanghai Jiao Tong University Spring 2012.
1 CS.217 Operating System By Ajarn..Sutapart Sappajak,METC,MSIT Chapter 6 Deadlocks Slide 1 Chapter 6 Deadlocks.
7.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 7: Deadlocks.
Operating Systems Unit 4: – Dining Philosophers – Deadlock – Indefinite postponement Operating Systems.
Silberschatz, Galvin and Gagne ©2009 Edited by Khoury, 2015 Operating System Concepts – 9 th Edition, Chapter 7: Deadlocks.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
CS162 Section 2. True/False A thread needs to own a semaphore, meaning the thread has called semaphore.P(), before it can call semaphore.V() False: Any.
NETW 3005 Monitors and Deadlocks. Reading For this lecture, you should have read Chapter 7. NETW3005 (Operating Systems) Lecture 06 - Deadlocks2.
Process Management Deadlocks.
Concurrency: Deadlock and Starvation
CS703 – Advanced Operating Systems
Applied Operating System Concepts -
CS703 - Advanced Operating Systems
CSCI 511 Operating Systems Chapter 5 (Part C) Monitor
September 19, 2012 Ion Stoica CS162 Operating Systems and Systems Programming Lecture 7 Semaphores, Conditional Variables,
Anthony D. Joseph and Ion Stoica
Deadlock B.Ramamurthy CSE421 1/11/2019 B.Ramamurthy.
CS162 Operating Systems and Systems Programming Lecture 7 Semaphores, Conditional Variables, Deadlocks February 13, 2013 Anthony D. Joseph
Anthony D. Joseph and Ion Stoica
Deadlock B.Ramamurthy CSE421 4/23/2019 B.Ramamurthy.
OPERATING SYSTEMS DEADLOCKS.
Deadlock B.Ramamurthy CSE421 5/1/2019 B.Ramamurthy.
CSE 542: Operating Systems
CSE 542: Operating Systems
Presentation transcript:

CS 162 Discussion Section Week 4

Administrivia Design reviews Friday, Monday and Tuesday – Every member must attend – Will test that every member understands YOU are responsible for testing your code – We provide access to a simple autograder – But your project is graded against a much more extensive autograder

Design Document Structure Each part of the project should be explained using the following structure Overview Correctness Constraints Declarations Descriptions Testing Plan

Project Questions?

What is Busy-Waiting?

Is Busy-Waiting always bad?

How is interrupt handling performed when a thread is put to sleep?

Semaphore.java /** * Atomically wait for this semaphore to become non-zero and decrement it. */ public void P() { boolean intStatus = Machine.interrupt().disable(); if (value == 0) { waitQueue.waitForAccess(KThread.currentThread()); KThread.sleep(); } else { value--; } Machine.interrupt().restore(intStatus); }

What is the problem? struct List { int data; struct List *next; }; List *list = 0; insert(int data) { List *l = new List; l->data = data; l->next = list; // A list = l; // B } Lock list_lock; // one per list insert(int data){ List *l = new List; l->data = data; acquire(&list_lock); l->next = list ; // A list = l; // B release(&list_lock); } Example Source:

What is a monitor? What is the benefit of using them?

Java Language Support for Synchronization Java has synchronized statements: synchronized (object) { … } –Since every Java object has an associated lock, this type of statement acquires and releases the object’s lock on entry and exit of the code block –Works properly even with exceptions: synchronized (object) { … DoFoo(); … } void DoFoo() { throw errException; }

Java Language Support for Synchronization In addition to a lock, every object has a single condition variable associated with it –How to wait inside a synchronization method of block: void wait(); void wait(long timeout); // Wait for timeout –How to signal in a synchronized method or block: void notify();// wakes up oldest waiter void notifyAll(); // like broadcast, wakes everyone –Condition variables can wait for a bounded length of time. This is useful for handling exception cases.

C++ Language Support for Synchronization Must catch all exceptions in critical sections –Catch exceptions, release lock, and re-throw exception: void Rtn() { lock.acquire(); try { … DoFoo(); … } catch (…) {// catch exception lock.release();// release lock throw; // re-throw the exception } lock.release(); } void DoFoo() { … if (exception) throw errException; … }

When does deadlock occur? How can we 1) prevent it, or 2) deal with it when it happens?

Four requirements for Deadlock Mutual exclusion –Only one thread at a time can use a resource. Hold and wait –Thread holding at least one resource is waiting to acquire additional resources held by other threads No preemption –Resources are released only voluntarily by the thread holding the resource, after thread is finished with it Circular wait –There exists a set {T 1, …, T n } of waiting threads T 1 is waiting for a resource that is held by T 2 T 2 is waiting for a resource that is held by T 3 … T n is waiting for a resource that is held by T 1

Is there a deadlock? T1T1 T2T2 T3T3 R1R1 R2R2 R3R3 R4R4 Simple Resource Allocation Graph

Is there a deadlock? T1T1 T2T2 T3T3 R1R1 R2R2 R3R3 R4R4 Allocation Graph With Deadlock

Is there a deadlock? T1T1 T2T2 T3T3 R2R2 R1R1 T4T4 Allocation Graph With Cycle, but No Deadlock

Deadlock Detection Algorithm Avail] = [FreeResources] Add all nodes to UNFINISHED do { done = true Foreach node in UNFINISHED { if ([Request node ] <= [Avail]) { remove node from UNFINISHED Avail] = [Avail] + [Alloc node ] done = false } } } until(done)

Resource Allocation Graph Examples T1T1 T2T2 T3T3 R1R1 R2R2 R3R3 R4R4 Simple Resource Allocation Graph T1T1 T2T2 T3T3 R1R1 R2R2 R3R3 R4R4 Allocation Graph With Deadlock T1T1 T2T2 T3T3 R2R2 R1R1 T4T4 Allocation Graph With Cycle, but No Deadlock –request edge – directed edge T i  R j –assignment edge – directed edge R j  T i

Methods for Handling Deadlocks Allow system to enter deadlock and then recover –Requires deadlock detection algorithm –Some technique for forcibly preempting resources and/or terminating tasks Deadlock prevention: ensure that system will never enter a deadlock –Need to monitor all lock acquisitions –Selectively deny those that might lead to deadlock Ignore the problem and pretend that deadlocks never occur in the system –Used by most operating systems, including UNIX

Techniques for Preventing Deadlock Make all threads request everything they’ll need at the beginning –Problem: Predicting future is hard, tend to over- estimate resources –Example: Don’t leave home until we know no one is using any intersection between here and where you want to go! Force all threads to request resources in a particular order preventing any cyclic use of resources –Thus, preventing deadlock –Example (x.P, y.P, z.P,…) Make tasks request disk, then memory, then…

Software Engineering

Use Software Tools Source revision control (CVS, SVN, git) –Easy to go back and see history –Figure out where and why a bug got introduced –Communicates changes to everyone Use an Integrated Development Environment –Structured development model Use automated testing tools –Write scripts for non-interactive software –Use “expect” for interactive software Use /IM to leave a history trail

Test Continuously Integration tests all the time, not on due date! –Write dummy stubs with simple functionality Let’s people test continuously, but more work –Schedule periodic integration tests Get everyone in the same room, check out code, build, and test. Testing types: –Unit tests: white-/black-box check each module in isolation (use JUnit?) –Random testing: Subject code to random timing changes Regression testing –Tendency is to test once and forget; what if something changes in some other part of the code?

Compare/Contrast the Waterfall, Rapid Prototyping, and Iterative models of software development

Waterfall –Top-down design, bottom-up implementation –Lots of upfront thinking, but slow, hard to iterate Rapid prototyping –Quick prototype, then discard and start over Iterative, or evolutionary processes –Build a prototype quickly (and ship/deploy it), then evolve it over time –Postpone some of the thinking

Banker’s Algorithm Technique: pretend each request is granted, then run deadlock detection algorithm, substitute ([Request node ] ≤ [Avail])  ([Max node ]-[Alloc node ] ≤ [Avail]) [FreeResources]: Current free resources each type [Alloc X ]: Current resources held by thread X [Max X ]: Max resources requested by thread X [Avail] = [FreeResources] Add all nodes to UNFINISHED do { done = true Foreach node in UNFINISHED { if ([Max node ]–[Alloc node ]<= [Avail]) { remove node from UNFINISHED [Avail] = [Avail] + [Alloc node ] done = false } } } until(done)