CS533 Concepts of Operating Systems Class 3 Monitors.

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

CHAPTER3 Higher-Level Synchronization and Communication
1 Chapter 5 Concurrency: Mutual Exclusion and Synchronization Principals of Concurrency Mutual Exclusion: Hardware Support Semaphores Readers/Writers Problem.
Ch 7 B.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Chapter 6: Process Synchronization
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo.
Operating Systems CMPSC 473 Mutual Exclusion Lecture 13: October 12, 2010 Instructor: Bhuvan Urgaonkar.
CS533 Concepts of Operating Systems Class 3 Monitors.
CS533 Concepts of Operating Systems Class 3 Data Races and the Case Against Threads.
1 CS 333 Introduction to Operating Systems Class 6 – Monitors and Message Passing Jonathan Walpole Computer Science Portland State University.
CS533 Concepts of Operating Systems Class 3 Monitors.
Chapter 6: Process Synchronization. Outline Background Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Objectives Understand.
1 CS 333 Introduction to Operating Systems Class 6 – Monitors and Message Passing Jonathan Walpole Computer Science Portland State University.
Synchronization: Monitors Hank Levy. 6/21/20152 Synchronization with Semaphores Semaphores can be used to solve any of the traditional synchronization.
Concurrency: Mutual Exclusion, Synchronization, Deadlock, and Starvation in Representative Operating Systems.
Silberschatz, Galvin and Gagne ©2007 Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Process Synchronization (Or The “Joys” of Concurrent.
CS533 Concepts of Operating Systems Class 1
Monitors CSCI 444/544 Operating Systems Fall 2008.
02/23/2004CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
CS533 - Concepts of Operating Systems 1 Class Discussion.
Race Conditions CS550 Operating Systems. Review So far, we have discussed Processes and Threads and talked about multithreading and MPI processes by example.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
Adopted from and based on Textbook: Operating System Concepts – 8th Edition, by Silberschatz, Galvin and Gagne Updated and Modified by Dr. Abdullah Basuhail,
/ PSWLAB Eraser: A Dynamic Data Race Detector for Multithreaded Programs By Stefan Savage et al 5 th Mar 2008 presented by Hong,Shin Eraser:
Monitors: An Operating System Structuring Concept
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
CS510 Concurrent Systems Introduction to Concurrency.
1 CS 333 Introduction to Operating Systems Class 6 – Monitors and Message Passing Jonathan Walpole Computer Science Portland State University.
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.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
CSC321 Concurrent Programming: §5 Monitors 1 Section 5 Monitors.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
CS533 - Concepts of Operating Systems 1 Anyone NOT on this list see me after class! Arryadi, Rizal Carlson, Kristen Ellet, Burke Florey, David Greenwald,
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Background The.
Chapter 6: Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
1 Condition Variables CS 241 Prof. Brighten Godfrey March 16, 2012 University of Illinois.
Operating Systems CSE 411 CPU Management Dec Lecture Instructor: Bhuvan Urgaonkar.
Problems with Semaphores Used for 2 independent purposes –Mutual exclusion –Condition synchronization Hard to get right –Small mistake easily leads to.
Eraser: A dynamic Data Race Detector for Multithreaded Programs Stefan Savage, Michael Burrows, Greg Nelson, Patrick Sobalvarro, Thomas Anderson Presenter:
CS533 Concepts of Operating Systems Class 2a Monitors.
CS533 Concepts of Operating Systems Class 2 Overview of Threads and Concurrency.
CS510 Concurrent Systems Jonathan Walpole. Introduction to Concurrency.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
Chapter 6 Synchronization Dr. Yingwu Zhu. The Problem with Concurrent Execution Concurrent processes (& threads) often access shared data and resources.
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.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Process Synchronization: Semaphores
Background on the need for Synchronization
CS533 Concepts of Operating Systems Class 3
Jonathan Walpole Computer Science Portland State University
CS510 Operating System Foundations
CS510 Operating System Foundations
Semaphore Originally called P() and V() wait (S) { while S <= 0
Process Synchronization
Lecture 2 Part 2 Process Synchronization
CS533 Concepts of Operating Systems Class 3
CSE 451: Operating Systems Autumn Lecture 8 Semaphores and Monitors
CSE 451: Operating Systems Autumn Lecture 7 Semaphores and Monitors
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
Synchronization: Monitors
CSE 153 Design of Operating Systems Winter 19
CS333 Intro to Operating Systems
Eraser: A dynamic data race detector for multithreaded programs
Presentation transcript:

CS533 Concepts of Operating Systems Class 3 Monitors

CS533 - Concepts of Operating Systems 2 But first …  … catch up from last time o synchronization errors and Eraser

CS533 - Concepts of Operating Systems 3 Enforcing mutual exclusion  Assumptions: o Every thread sets the lock before accessing shared data! o Every thread releases the lock after it is done!  Only works if you follow these programming conventions all the time! Thread 1 Thread 2 Thread 3 Lock Lock A = 2 A = A+1 A = A*B Unlock Unlock

CS533 - Concepts of Operating Systems 4 Solutions to misuse (or no use) of locks  Solution 1 - detection o use static or dynamic checking tools to help track down misuses of locking primitives (synchronization bugs) o How much can you detect?  Solution 2 - prevention o have the compiler insert the synchronization primitives for you automatically o Which errors can be prevented this way, and which can’t?

CS533 - Concepts of Operating Systems 5 Solution 1: Checking tools (class 2 cont.)  Eraser o A dynamic checker that uses binary re-writing techniques o Gathers an “execution history” of reads, writes and lock acquisitions o Evaluates consistency with rules  Is it enough to simply check that some lock is held whenever a global variable is accessed?

CS533 - Concepts of Operating Systems 6 Automated checking of conventions  Eraser doesn’t know ahead of time which locks protect which variables  It infers which locks protect which variables using a lock-set algorithm o Assume all locks are candidates for a variable ( C(v) is full) o For each access take intersection of C(v) and locks held by thread and make these the candidate set C(v) o If C(v) becomes empty, issue warning

CS533 - Concepts of Operating Systems 7 Improving the locking discipline  The standard approach produces many false positives that arise due to special cases:  Initialization o No need to lock if no thread has a reference yet  Read sharing o No need to lock if all threads are readers  Reader/writer locking o Distinguish concurrent readers from concurrent readers and writers

CS533 - Concepts of Operating Systems 8 Improved algorithm virgin exclusive shared Modified (race?) rd, wr First thread wr rd, new thread wr, new thread wr rd

CS533 - Concepts of Operating Systems 9 What can’t it detect?  Deadlocks?  Races that do not manifest themselves in this particular execution run  It can’t prove the absence of errors, it can only show the presence of errors

CS533 - Concepts of Operating Systems 10 Solution 2: Monitors  Monitors employ two key concepts, both of which can be automated by a compiler: o Encapsulation: Local data variables are accessible only via the monitor’s entry procedures (like methods) o Mutual exclusion: The entry procedures are treated as critical sections

CS533 - Concepts of Operating Systems 11 Two kinds of synchronization  Mutual exclusion o Only one at a time in the critical section  Condition synchronization o Wait (block) until a certain condition holds o Signal (unblock) waiting threads when the condition holds

CS533 - Concepts of Operating Systems 12 Logical view of monitor structures initialization code “entry” methods y x shared data condition variables monitor entry queue List of threads waiting to enter the monitor Can be called from outside the monitor. Only one active at any moment. Local to monitor (Each has an associated list of waiting threads) local methods

CS533 - Concepts of Operating Systems 13 Implementing mutual exclusion for monitors  How can we implement mutual exclusion for monitor procedures?

CS533 - Concepts of Operating Systems 14 Implementing mutual exclusion for monitors  How can we implement mutual exclusion for monitor procedures? o Will spinning locks work?

CS533 - Concepts of Operating Systems 15 Implementing mutual exclusion for monitors  How can we implement mutual exclusion for monitor procedures? o Will spinning locks work? o Will yielding locks work?

CS533 - Concepts of Operating Systems 16 Implementing mutual exclusion for monitors  How can we implement mutual exclusion for monitor procedures? o Will spinning locks work? o Will yielding locks work? o What if we don’t have atomic instructions?

CS533 - Concepts of Operating Systems 17 Implementing mutual exclusion for monitors  How can we implement mutual exclusion for monitor procedures? o Will spinning locks work? o Will yielding locks work? o What if we don’t have atomic instructions?  Idea 1 (assuming uniprocessor): o Disable interrupts during monitor procedures

CS533 - Concepts of Operating Systems 18 A Simple Example  Goal: to build a blocking mutex lock using monitors o Monitor procedures are “acquire” and “release”  Demonstrate use of interrupt disabling on a uniprocessor to implement mutual exclusion within the monitor procedures

CS533 - Concepts of Operating Systems 19 Using monitors to build a blocking mutex Blocking_mutex:monitor Begin busy:boolean; nonbusy:condition; busy:=false; // initial value Procedure acquire() Begin if busy then nonbusy.wait; busy:=true; End Procedure release() Begin busy:=false; nonbusy.signal End; End Blocking_mutex;

CS533 - Concepts of Operating Systems 20 Using monitors to build a blocking mutex Blocking_mutex:monitor Begin busy:boolean; nonbusy:condition; Busy:=false; // initial value Procedure acquire() Begin<----- disable interrupts if busy then nonbusy.wait; busy:=true; End<----- enable interrupts Procedure release() Begin<----- disable interrupts busy:=false; nonbusy.signal End;<----- enable interrupts End Blocking_mutex;

CS533 - Concepts of Operating Systems 21 Using monitors to build a blocking mutex Blocking_mutex:monitor Begin busy:boolean; nonbusy:condition; Busy:=false; // initial value Procedure acquire() Begin----- disable interrupts if busy then nonbusy.wait; <----- ???? busy:=true; End----- enable interrupts Procedure release() Begin----- disable interrupts busy:=false; nonbusy.signal<----- ???? End;----- enable interrupts End Blocking_mutex;

CS533 - Concepts of Operating Systems 22 Implementing condition variables  Wait o Add process to queue of processes waiting on this condition o Suspend process o Release monitor’s mutual exclusion Wake up / schedule next process trying to enter monitor Reenable interrupts?  Signal o Wake up / schedule first process waiting on this condition o Release monitor’s mutual exclusion by enabling interrupts? o Suspend yourself On what? … and how do you ever wake up again?

CS533 - Concepts of Operating Systems 23 Implementing mutual exclusion for monitors  How can we implement mutual exclusion for monitor procedures? o Will spinning locks work? o Will yielding locks work? o What if we don’t have atomic instructions?  Idea 1: o Disable interrupts during monitor procedures  Idea 2: o Use binary semaphores

CS533 - Concepts of Operating Systems 24 Building monitors from binary semaphores  See example in paper

CS533 - Concepts of Operating Systems 25 Bounded buffer solution with monitors process Producer begin loop BoundedBuffer.append(c) end loop end Producer process Consumer begin loop BoundedBuffer.remove(c) end loop end Consumer BoundedBuffer: monitor var buffer :...; nextIn, nextOut :... ; procedure append (c: char) begin... end procedure remove (var c: char) begin... end end BoundedBuffer

CS533 - Concepts of Operating Systems 26 Bounded buffer solution with monitors BoundedBuffer: monitor var buffer : array[0..n-1] of char nextIn,nextOut : 0..n-1 := 0 Count : 0..n := 0 nonEmpty, nonFull : condition procedure append(c:char) procedure remove(var c: char) begin begin if (Count = n) then if (Count = n) then wait(nonFull) wait(nonEmpty) end if end if buffer[nextIn] := c c := buffer[nextOut] nextIn := nextIn+1 mod n nextOut := nextOut+1 mod n Count := Count+1 Count := Count-1 signal(nonEmpty) signal(nonFull) end append end remove end BoundedBuffer

CS533 - Concepts of Operating Systems 27 Alarm clock example AlarmClock: monitor Begin now: integer; wakeup: condition; now := 0; Procedure wakeme(n: integer); Begin alarmsetting: integer; alarmsetting := now + n; While now < alarmsetting do wakeup.wait (alarmsetting); wakeup.signal; End; Procedure tick; Begin now := now + 1; wakeup.signal; End; End AlarmClock;

CS533 - Concepts of Operating Systems 28 Semantics of condition variables  How many blocked threads should be woken on a signal?  Which blocked thread should be woken on a signal?  In what order should newly awoken threads acquire the mutex?  Should the signaler immediately free the mutex? o If so, what if it has more work to do? o If not, how can the signaled process continue?  What if signal is called before the first wait?

CS533 - Concepts of Operating Systems 29 Subtle race conditions  Why does wait on a condition variable need to “atomically” unlock the mutex and block the thread?  Why does the thread need to re-lock the mutex when it wakes up from wait? o Can it assume that the condition it waited on now holds?

CS533 - Concepts of Operating Systems 30 Comparison with thread primitives  How do Hoare’s monitors compare to the use of mutexes and condition variables described by Birrell?

CS533 - Concepts of Operating Systems 31 Deadlock (nested monitor problem) Procedure Get(); BEGIN LOCK a DO LOCK b DO WHILE NOT ready DO wait(b,c) END; END; END Get; Procedure Give(); BEGIN LOCK a DO LOCK b DO ready := TRUE; signal(c); END; END Give;

CS533 - Concepts of Operating Systems 32 Reader/writer locking  Writers exclude readers and writers  Readers exclude writers but not readers  Example (page 15, Birrell) o Good use of broadcast in ReleaseExclusive() o Results in “spurious wake-ups” o … and “spurious lock conflicts” o How could you use signal instead?  Move signal/broadcast call after release of mutex? o Advantages? Disadvantages?  Can we avoid writer starvation?