Homework 4.

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Synchronization NOTE to instructors: it is helpful to walk through an example such as readers/writers locks for illustrating the use of condition variables.
Synchronization with Eventcounts and Sequencers
Ch 7 B.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Monitors & Blocking Synchronization 1. Producers & Consumers Problem Two threads that communicate through a shared FIFO queue. These two threads can’t.
1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Homework 6 Sarah Diesburg Operating Systems CS 3430.
Operating Systems CMPSC 473 Mutual Exclusion Lecture 13: October 12, 2010 Instructor: Bhuvan Urgaonkar.
COSC 3407: Operating Systems Lecture 8: Semaphores, Monitors and Condition Variables.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
1 Last Time: Locks & Semaphores Implementing locks Test & Set Busy waiting Block waiting Semaphores Generalization of locks.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
CS444/CS544 Operating Systems Synchronization 2/21/2007 Prof. Searleman
Chapter 2.3 : Interprocess Communication
Chapter 6 – Concurrent Programming Outline 6.1 Introduction 6.2Monitors 6.2.1Condition Variables 6.2.2Simple Resource Allocation with Monitors 6.2.3Monitor.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Operating Systems CMPSCI 377 Lecture.
Monitors: An Operating System Structuring Concept
Monitor  Giving credit where it is due:  The lecture notes are borrowed from Dr. I-Ling Yen at University of Texas at Dallas  I have modified them and.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Operating Systems CMPSCI 377 Lecture.
6.3 Peterson’s Solution The two processes share two variables: Int turn; Boolean flag[2] The variable turn indicates whose turn it is to enter the critical.
Critical Problem Revisit. Critical Sections Mutual exclusion Only one process can be in the critical section at a time Without mutual exclusion, results.
Semaphores, Locks and Monitors By Samah Ibrahim And Dena Missak.
1 Chapter 2.3 : Interprocess Communication Process concept  Process concept  Process scheduling  Process scheduling  Interprocess communication Interprocess.
CSC321 Concurrent Programming: §5 Monitors 1 Section 5 Monitors.
Suggested Exercises 5. Question #1 Find a creative/funny example of synchronization that can demonstrate the difficulty of developing a monitor-based.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
More on Semaphores Andy Wang Operating Systems COP 4610 / CGS 5765.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-5 Process Synchronization Department of Computer Science and Software.
1 Condition Variables CS 241 Prof. Brighten Godfrey March 16, 2012 University of Illinois.
Thread Synchronization including Mutual Exclusion In Java synchronized keyword Monitor or Lock with conditions Semaphore.
Problems with Semaphores Used for 2 independent purposes –Mutual exclusion –Condition synchronization Hard to get right –Small mistake easily leads to.
COSC 3407: Operating Systems Lecture 9: Readers-Writers and Language Support for Synchronization.
Concurrency in Shared Memory Systems Synchronization and Mutual Exclusion.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
1 Previous Lecture Overview  semaphores provide the first high-level synchronization abstraction that is possible to implement efficiently in OS. This.
Chapter 71 Monitor for Reader/Writers  Synchronizes access if all processes follow.  If some don’t go through monitor and database is accessed directly,
Homework-6 Questions : 2,10,15,22.
Implementing Mutual Exclusion Andy Wang Operating Systems COP 4610 / CGS 5765.
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.
Rensselaer Polytechnic Institute CSCI-4210 – Operating Systems David Goldschmidt, Ph.D.
6.1 Silberschatz, Galvin and Gagne ©2005 Operating System Principles 6.5 Semaphore Less complicated than the hardware-based solutions Semaphore S – integer.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
1 Section 5 Synchronization primitives (Many slides taken from Winter 2006)
CS703 - Advanced Operating Systems
CS703 – Advanced Operating Systems
Process Synchronization: Semaphores
Suggested Exercises 5.
Monitors, Condition Variables, and Readers-Writers
CSCI 511 Operating Systems Chapter 5 (Part C) Monitor
Concurrency: Mutual Exclusion and Synchronization
Anthony D. Joseph and Ion Stoica
Semaphore Originally called P() and V() wait (S) { while S <= 0
CS703 - Advanced Operating Systems
Critical section problem
Implementing Mutual Exclusion
Monitor Giving credit where it is due:
Implementing Mutual Exclusion
CSE 153 Design of Operating Systems Winter 2019
CSE 542: Operating Systems
Review The Critical Section problem Peterson’s Algorithm
Presentation transcript:

Homework 4

Question #1 Find a creative/funny example of synchronization that can demonstrate the difficulty of developing a monitor-based solution (in pseudocode) similar to the “Readers-Writers.” Make sure that you vigorously discuss the correctness and pitfalls of your solution.

Gas Station Problem There is a common price for gas Consumers never modify the price – they just pump gas Owners read modify the price We want one owner at a time, but many consumers at the same time

Developing the Solution Global states: activeConsumers = 0; activeOwners = 0; waitingConsumers = 0; waitingOwners = 0; Condition okToPump = NULL; Condition okToChangePrice = NULL; Lock lock = FREE;

Sample Code Solution – up to you to prove correctness Consumer() { lock.Acquire(); while (activeOwners > 0 || waitingOwners > 0) { ++waitingConsumers; okToPump.Wait(&lock); --waitingConsumers; } ++activeConsumers; lock.Release(); // access price and pumps --activeConsumers; if (activeConsumers == 0 && waitingOwners > 0) { okToChangePrice.Signal(&lock); Writer() { lock.Acquire(); while (activeOwners > 0 || activeConsumers > 0) { ++waitingOwners; okToChangePrice.Wait(&lock); --waitingOwners; } ++activeOwners; lock.Release(); // access database --activeOwners; if (waitingOwners > 0) { okToChangePrice.Signal(&lock); } else if (waitingConsumers > 0) { okToPump.Broadcast(&lock);

Question #2 Find a creative/funny example of deadlock, and apply various deadlock prevention approaches to the live example. Describe the advantages and disadvantages of each approach.

A Tale of Two Fisherman Two fisherman are out fishing, but between them they only have one fishing pole and one bait. If one takes the pole, and the other takes the bait… They deadlock!

Solutions Infinite resources No sharing Buy more poles and bait No sharing They each have their own poles and bait, fish alone Allocate all resources at the beginning They each either get both things or none

Solutions Allocate all resources at the beginning They each either get both things or none semaphore pole= 1 semaphore bait= 1 lock = 1; fisher(int j) { while (TRUE) { P(s); P(pole); P(bait); // fish V(bait); V(pole); V(s); }

Solutions Make everyone use the same ordering Fisherman 1 goes first, then fisherman 2 (round robin)

Question 3: Helicopter Problem A helicopter ride has five seats, and it always carries a full load. Use lock(s) and condition variable(s) to write a procedure PersonArrives(), which is called whenever a person (thread) arrives. Once the load is full, one person (thread) should call UpAndAway(), and five threads should return from PersonArrives(). There should be no undue waiting: the helicopter should depart as soon as it has a full load.

Helicopter Problem int queue = 0; condition okToGo = NULL; Lock lock = FREE; PersonArrives() { lock.Acquire(); ++queue; if (queue < 4) { okToGo.wait(&lock); } else { GoGoGo(); queue = 0; okToGo.Signal(&lock); } lock.Release();

Helicopter Problem int queue = 0; condition okToGo = NULL; Lock lock = FREE; PersonArrives() { lock.Acquire(); ++queue; if (queue < 5) { okToGo.wait(&lock); } else { UpAndAway();= 0; okToGo.Signal(&lock); } lock.Release();

Helicopter Problem int queue = 0; condition okToGo = NULL; Lock lock = FREE; PersonArrives() { lock.Acquire(); ++queue; if (queue < 5) { okToGo.wait(&lock); } else { UpAndAway(); okToGo.Signal(&lock); queue = 0; } lock.Release();

Proving Correctness Mutual exclusion All shared variables are locked e.g., queue Signal() and Wait() are invoked between lock.Acquire() and lock.Release()

Proving Correctness Liveness Maximum of 4 threads in okToGo.wait() Every 5th thread wakes up exactly four threads already waiting in okToGo.wait() Additional threads wait at lock.Acquire() As long as we have 5n threads, every thread will make progress

Proving Correctness Fairness As long as we have FIFO queues at lock.Acquire() The queuing policy at okToGo.wait() does not matter, since all four waiting threads will be awakened As long as we have 5n threads Every thread will get its chance

Common Pitfall Wait() requires lock on return No lock.Release() int queue = 0; condition okToGo = NULL; Lock lock = FREE; PersonArrives() { lock.Acquire(); ++queue; if (queue < 5) { okToGo.wait(&lock); } else { UpAndAway(); okToGo.Signal(&lock); queue = 0; lock.Release(); } Wait() requires lock on return No lock.Release()