Monitors CSCI 444/544 Operating Systems Fall 2008.

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

Operating Systems: Monitors 1 Monitors (C.A.R. Hoare) higher level construct than semaphores a package of grouped procedures, variables and data i.e. object.
Chapter 6: Process Synchronization
1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo.
02/27/2004CSCI 315 Operating Systems Design1 Process Synchronization Deadlock Notice: The slides for this lecture have been largely based on those accompanying.
Monitors A high-level abstraction that provides a convenient and effective mechanism for process synchronization Only one process may be active within.
Monitors Chapter 7. The semaphore is a low-level primitive because it is unstructured. If we were to build a large system using semaphores alone, the.
1 Semaphores and Monitors: High-level Synchronization Constructs.
COSC 3407: Operating Systems Lecture 8: Semaphores, Monitors and Condition Variables.
Dining-Philosophers Problem Shared data fork[5]: semaphore; initialized to 1.
02/19/2010CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
1 Last Time: Locks & Semaphores Implementing locks Test & Set Busy waiting Block waiting Semaphores Generalization of locks.
1 Thursday, June 22, 2006 "I think I've got the hang of it now.... :w :q :wq :wq! ^d X exit ^X^C ~. ^[x X Q :quitbye CtrlAltDel ~~q :~q logout save/quit.
Synchronization: Monitors Hank Levy. 6/21/20152 Synchronization with Semaphores Semaphores can be used to solve any of the traditional synchronization.
Process Synchronization
Semaphores CSCI 444/544 Operating Systems Fall 2008.
What we will cover… Process Synchronization Basic Concepts
02/25/2004CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Operating Systems CMPSCI 377 Lecture.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Module 6: Process Synchronization.
More Synchronisation Last time: bounded buffer, readers-writers, dining philosophers Today: sleeping barber, monitors.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Background Concurrent.
Synchronization II: CPE Operating Systems
5.1 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts Essentials – 9 th Edition Problems with Semaphores Incorrect use of semaphore operations:
1 Chapter 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Special Machine Instructions for Synchronization Semaphores.
Chap 6 Synchronization. Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms.
Chapter 6: Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Synchronization Background The Critical-Section.
11/21/20151 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC Based on slides by Roy Campbell, Sam.
CSE 451: Operating Systems Winter 2012 Semaphores and Monitors Mark Zbikowski Gary Kimura.
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.
CSE 451: Operating Systems Winter 2014 Module 8 Semaphores, Condition Variables, and Monitors Mark Zbikowski Allen Center 476 ©
Problems with Semaphores Used for 2 independent purposes –Mutual exclusion –Condition synchronization Hard to get right –Small mistake easily leads to.
CS533 – Spring Jeanie M. Schwenk Experiences and Processes and Monitors with Mesa What is Mesa? “Mesa is a strongly typed, block structured programming.
Operating Systems Lecture Notes Synchronization Matthew Dailey Some material © Silberschatz, Galvin, and Gagne, 2002.
U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Synchronization Emery Berger and Mark Corner University.
IT 344: Operating Systems Winter 2008 Module 7 Semaphores and Monitors
CSC 360 Instructor: Kui Wu More on Process Synchronization Semaphore, Monitor, Condition Variables.
Dining Philosophers & Monitors Questions answered in this lecture: How to synchronize dining philosophers? What are monitors and condition variables? What.
1 Advanced Operating Systems - Fall 2009 Lecture 7 – February 2, 2009 Dan C. Marinescu Office: HEC 439 B. Office hours:
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.
Deadlock and Starvation
CS703 - Advanced Operating Systems
CSE 120 Principles of Operating
Semaphore Synchronization tool that provides more sophisticated ways (than Mutex locks) for process to synchronize their activities. Semaphore S – integer.
Chapter 5: Process Synchronization – Part 3
Chapter 5: Process Synchronization
Deadlock and Starvation
Monitors, Condition Variables, and Readers-Writers
CS510 Operating System Foundations
Chapter 6: Process Synchronization
CSCI 511 Operating Systems Chapter 5 (Part C) Monitor
Chapter 5: Process Synchronization (Con’t)
Lecture 25 Syed Mansoor Sarwar
Threading And Parallel Programming Constructs
Chapter 7: Synchronization Examples
Synchronization, Monitors, Deadlocks
More Synchronization Readers and Writers.
CSE 451: Operating Systems Winter 2004 Module 7+ Monitor Supplement
CSE 451: Operating Systems Winter Module 8 Semaphores and Monitors
CSE 451: Operating Systems Autumn Lecture 8 Semaphores and Monitors
Monitors Chapter 7.
Monitor Giving credit where it is due:
CSE 451: Operating Systems Autumn Lecture 7 Semaphores and Monitors
CSE 451: Operating Systems Autumn Module 8 Semaphores and Monitors
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
Synchronization: Monitors
CSE 153 Design of Operating Systems Winter 19
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
Presentation transcript:

Monitors CSCI 444/544 Operating Systems Fall 2008

Agenda What is monitor? Condition variables Hoare monitor vs Mesa monitor Solution to Dining Philosophers

Background Motivation Users can inadvertently misuse locks and semaphores –E.g., never unlock a mutex Address the key usability issues that arise with semaphores Idea Provide language support to automatically lock and unlock monitor lock when in critical section –Lock is added implicitly, never seen by user Provide condition variables for scheduling constraints

Monitors A monitor is: a programming language construct that supports controlled access to shared data –Synchronization code is added by the compiler A monitor encapsulates: shared data structures procedures that operate on the shared data synchronization between concurrent threads that invoke those procedures Data can only be accessed from within the monitor, using the provided procedures protects the data from unstructured access

Schematic View of a Monitor waiting queue of threads trying to enter the monitor at most one thread in monitor at a time

Semaphore vs Monitor Semaphores used for both mutual exclusion and scheduling constraints + elegant (one mechanism for both purpose) - code can be hard to read and hard to get right Monitors use separate mechanisms for the two purposes use locks for mutual exclusion use condition variables for scheduling constraints

Monitor Lock “Automatic” mutual exclusion only one thread can be executing inside at any time –thus, synchronization is implicitly associated with the monitor – it “comes for free” if a second thread tries to execute a monitor procedure, it blocks until the first has left the monitor –more restrictive than semaphores –but easier to use (most of the time) Monitor lock Lock before accessing shared data release after finishing with shared data Lock is initially free

Condition Variables Main idea: make it possible for thread to sleep inside a critical section, by atomically Releasing lock Putting thread on wait queue and go to sleep A rendezvous point Each condition variable has a queue of waiting thread

Monitor with Condition Variables

Operations on Condition Variables Three operations on condition variables wait(c) –release monitor lock, so somebody else can get in –wait for somebody else to signal condition –thus, condition variables have associated wait queues signal(c) –wake up at most one waiting thread –if no waiting threads, signal is lost this is different than semaphores: no history! broadcast(c) –wake up all waiting threads

After Signal(c) … Who runs when the signal(c) is done and there is a thread waiting on the condition variable? Depends on who runs (waiter or signaler), we have two types of monitors - Hoare monitors: waiter runs - Mesa monitors: signaler continues

Hoare Monitors signal(c) means run waiter immediately –give higher priority to waiter signaler blocks immediately –condition guaranteed to hold when waiter runs –but, signaler must restore monitor invariants before signaling! cannot leave a mess for the waiter, who will run immediately! lock switch –signal gives up lock –wait acquires lock –signaler re-acquires lock after waiter unlock

Mesa Monitors signal(c) means waiter is made ready, but the signaler continues –waiter runs when signaler leaves monitor (or waits to re-enter monitor) signaler need not restore invariant until it leaves monitor being woken up is only a hint that something has changed –signaled condition may no longer hold –must re-check conditional case

Hoare vs. Mesa Monitors Hoare monitors: Mesa monitors: Mesa monitors easier to use more efficient fewer switches directly supports broadcast Most OSes use Hoare monitors leave less to chance when wake up, condition guaranteed to be what you expect if (notReady) wait(c) while (notReady) wait(c)

More about Monitor Language supports monitors A monitor is a software module with OO design feature –encapsulation Compiler understands them compiler inserts calls to runtime routines for –monitor entry –monitor exit –signal –wait Runtime system implements these routines moves threads on and off queues ensures mutual exclusion!

Solution to Dining-Philosophers Introduce state variable for each philosopher i state[i] = THINKING, HUNGRY, or EATING Safety: No two adjacent philosophers eat simultaneously for all i: !(state[i]==EATING && state[i+1%5]==EATING) Liveness: Not the case that a philosopher is hungry and his neighbors are not eating for all i: !(state[i]==HUNGRY && (state[i+4%5]!=EATING && state[i+1%5]!=EATING))

Solution to DP monitor DP { enum { THINKING; HUNGRY, EATING) state [5] ; condition self [5]; void pickup (int i) { state[i] = HUNGRY; test(i); if (state[i] != EATING) self [i].wait; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5); }

Solution to DP (cont) void test (int i) { if ( (state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5] != EATING) ) { state[i] = EATING ; self[i].signal () ; } initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING; }