Operating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst

Similar documents
What's wrong with Semaphores?

Condition Variables. Dongkun Shin, SKKU

Condition Variables. Dongkun Shin, SKKU

Last Class: Synchronization. Review. Semaphores. Today: Semaphores. MLFQ CPU scheduler. What is test & set?

CIS Operating Systems Application of Semaphores. Professor Qiang Zeng Spring 2018

Lecture 8: September 30

Deadlock and Monitors. CS439: Principles of Computer Systems September 24, 2018

Condition Variables. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University

Condition Variables. Figure 29.1: A Parent Waiting For Its Child

Deadlock and Monitors. CS439: Principles of Computer Systems February 7, 2018

CS 470 Spring Mike Lam, Professor. Semaphores and Conditions

Synchroniza+on II COMS W4118

W4118 Operating Systems. Instructor: Junfeng Yang

CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring Lecture 8: Semaphores, Monitors, & Condition Variables

Concurrent Programming Lecture 10

30. Condition Variables

Synchronization II. Today. ! Condition Variables! Semaphores! Monitors! and some classical problems Next time. ! Deadlocks

Condition Variables CS 241. Prof. Brighten Godfrey. March 16, University of Illinois

CS 537 Lecture 8 Monitors. Thread Join with Semaphores. Dining Philosophers. Parent thread. Child thread. Michael Swift

Operating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst

Operating systems and concurrency (B08)

CMSC421: Principles of Operating Systems

Review: Processes. A process is an instance of a running program. POSIX Thread APIs:

CS 153 Lab6. Kishore Kumar Pusukuri

Figure 30.1: A Parent Waiting For Its Child What we would like to see here is the following output:

Synchronization II. q Condition Variables q Semaphores and monitors q Some classical problems q Next time: Deadlocks

More Synchronization; Concurrency in Java. CS 475, Spring 2018 Concurrent & Distributed Systems

PRINCIPLES OF OPERATING SYSTEMS

Real-Time and Concurrent Programming Lecture 4 (F4): Monitors: synchronized, wait and notify

CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017

Overview. CMSC 330: Organization of Programming Languages. Concurrency. Multiprocessors. Processes vs. Threads. Computation Abstractions

CS 450 Exam 2 Mon. 4/11/2016

Reminder from last time

CS 2112 Lecture 20 Synchronization 5 April 2012 Lecturer: Andrew Myers

Real Time Operating Systems and Middleware

Programming in Parallel COMP755

Page 1. CS162 Operating Systems and Systems Programming Lecture 8. Readers-Writers Language Support for Synchronization

CONCURRENCY: DEADLOCK. Shivaram Venkataraman CS 537, Spring 2019

CS61B, Spring 2003 Discussion #17 Amir Kamil UC Berkeley 5/12/03

Synchronization II: EventBarrier, Monitor, and a Semaphore. COMPSCI210 Recitation 4th Mar 2013 Vamsi Thummala

Atomic Instructions! Hakim Weatherspoon CS 3410, Spring 2011 Computer Science Cornell University. P&H Chapter 2.11

Page 1. Goals for Today" Atomic Read-Modify-Write instructions" Examples of Read-Modify-Write "

Synchronization. Dr. Yingwu Zhu

CS533 Concepts of Operating Systems. Jonathan Walpole

Synchronising Threads

CS 450 Exam 2 Mon. 11/7/2016

Synchronization. Disclaimer: some slides are adopted from the book authors slides with permission 1

Operating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst

Monitors (Deprecated)

Today: Synchronization. Recap: Synchronization

Warm-up question (CS 261 review) What is the primary difference between processes and threads from a developer s perspective?

CS162 Operating Systems and Systems Programming Lecture 8. Readers-Writers Language Support for Synchronization

Page 1. Goals for Today" Atomic Read-Modify-Write instructions" Examples of Read-Modify-Write "

Note: in this document we use process and thread interchangeably.

Synchronization. CS 475, Spring 2018 Concurrent & Distributed Systems

Page 1. Goals for Today. Atomic Read-Modify-Write instructions. Examples of Read-Modify-Write

Data Races and Deadlocks! (or The Dangers of Threading) CS449 Fall 2017

Synchronization. CSCI 5103 Operating Systems. Semaphore Usage. Bounded-Buffer Problem With Semaphores. Monitors Other Approaches

Monitors; Software Transactional Memory

CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2004

Synchronization 1. Synchronization

Operating Systems. Thread Synchronization Primitives. Thomas Ropars.

Synchronization and Semaphores. Copyright : University of Illinois CS 241 Staff 1

CSE 153 Design of Operating Systems

Concurrency Control. Synchronization. Brief Preview of Scheduling. Motivating Example. Motivating Example (Cont d) Interleaved Schedules

Recap: Thread. What is it? What does it need (thread private)? What for? How to implement? Independent flow of control. Stack

Condition Variables & Semaphores

Last Class: CPU Scheduling! Adjusting Priorities in MLFQ!

Outline Part 2. Semaphores. Semaphore Usage. Objectives: Administrative details:

Systèmes d Exploitation Avancés

Concurrent Server Design Multiple- vs. Single-Thread

Java Threads. Written by John Bell for CS 342, Spring 2018

CS 6400 Lecture 11 Name:

Lecture 6 (cont.): Semaphores and Monitors

Monitors; Software Transactional Memory

G Programming Languages Spring 2010 Lecture 13. Robert Grimm, New York University

CSE 120 Principles of Operating Systems Spring 2016

Operating Systems, Assignment 2 Threads and Synchronization

Process Synchronization (Part I)

CSE 120 Principles of Operating Systems Spring 2016

Synchronization. CS 416: Operating Systems Design, Spring 2011 Department of Computer Science Rutgers University

CMSC421: Principles of Operating Systems

More Types of Synchronization 11/29/16

CS 318 Principles of Operating Systems

Concurrency. Chapter 5

Outline. CS4254 Computer Network Architecture and Programming. Introduction 2/4. Introduction 1/4. Dr. Ayman A. Abdel-Hamid.

CSci 4061 Introduction to Operating Systems. Synchronization Basics: Locks

Synchronization. CS61, Lecture 18. Prof. Stephen Chong November 3, 2011

Monitors & Condition Synchronization

CS 10: Problem solving via Object Oriented Programming Winter 2017

CS 333 Introduction to Operating Systems. Class 3 Threads & Concurrency. Jonathan Walpole Computer Science Portland State University

C09: Process Synchronization

Concurrent Programming using Threads

CS 550 Operating Systems Spring Concurrency Semaphores, Condition Variables, Producer Consumer Problem

EECS 482 Introduction to Operating Systems

CSE 451: Operating Systems Winter Lecture 7 Synchronization. Steve Gribble. Synchronization. Threads cooperate in multithreaded programs

But first... Re: generic parking. A cyclic POSIX thread (2) Real-time Systems SMD138. Lecture 14: Real-time languages (Burns & Wellings ch.

CMSC 330: Organization of Programming Languages. Threads Classic Concurrency Problems

Lecture Outline. CS 5523 Operating Systems: Concurrency and Synchronization. a = 0; b = 0; // Initial state Thread 1. Objectives.

COMP 346 WINTER Tutorial 5 MONITORS

Transcription:

Operating Systems CMPSCI 377 Spring 2017 Mark Corner University of Massachusetts Amherst

What is a Monitor? Ties data and the synchronization operations together Monitors guarantee mutual exclusion, i.e., only one thread may execute a given monitor method at a time. CS377: Operating Systems

Monitors: A Formal Definition A Monitor defines a lock and zero or more condition variables for managing concurrent access to shared data. The monitor uses the lock to insure that only a single thread is active in the monitor at any instance. The lock also provides mutual exclusion for shared data. Condition variables enable threads to go to sleep inside of critical sections, by releasing their lock at the same time it puts the thread to sleep. CS377: Operating Systems

Monitor Operations Encapsulates the shared data you want to protect. Acquires the mutex at the start. Operates on the shared data. Temporarily releases the mutex if it can't complete. Reacquires the mutex when it can continue. Releases the mutex at the end.

Monitors in Java class Queue { It is simple to turn a Java class into a monitor: Make all the data private Make all methods synchronized (or at least the non-private ones) private...; // queue data public void synchronized add( Object item ) { put item on queue; public Object synchronized remove() { if queue not empty { remove item; return item;

Condition Variables How can we change remove() to wait until something is on the queue? Logically, we want to go to sleep inside of the critical section But if we hold on to the lock and sleep, then other threads cannot access the shared queue, add an item to it, and wake up the sleeping thread Solution: use condition variables Condition variables enable a thread to sleep inside a critical section Any lock held by the thread is atomically released when the thread is put to sleep CS377: Operating Systems

Operations on CVs Condition variable: is a queue of threads waiting for something inside a critical section. Condition variables support three operations: 1. Wait(Lock lock): atomic (release lock, go to sleep), when the process wakes up it re-acquires lock. 2. Signal(): wake up waiting thread, if one exists. Otherwise, it does nothing. 3. Broadcast(): wake up all waiting threads Rule: thread must hold the lock when doing condition variable operations. CS377: Operating Systems

Condition Variables in Java class Queue { Use wait() to give up the lock private...; // queue data Use notify() to signal that the condition a thread is waiting on is satisfied. Use notifyall() to wake up all waiting threads. Effectively one condition variable per object. public void synchronized Add( Object item ) { put item on queue; notify (); public Object synchronized Remove() { while queue is empty wait (); // give up lock and go to sleep remove and return item;

Implicit Locks public Object synchronized Remove() { (lock) while queue is empty (unlock) wait (); (lock) remove and return item; (unlock)

Clicker Question #1 If you don t know the ordering of how threads get run, what could happen with an if instead of a while? (A) Always works fine (B) Remove may sleep forever (C) Items get duplicated (D) remove and return may get run on an empty queue public void synchronized Add( Object item ) { put item on queue; notify (); public Object synchronized Remove() { if queue is empty wait (); // give up lock and go to sleep remove and return item;

Answer on Next Slide

Mesa versus Hoare Monitors What should happen when signal() is called? No waiting threads => the signaler continues and the signal is effectively lost (unlike what happens with semaphores). If there is a waiting thread, one of the threads starts executing, others must wait Mesa-style: (Nachos, Java, and most real operating systems) The thread that signals keeps the lock (and thus the processor). The waiting thread waits for the lock. Hoare-style: (most textbooks) The thread that signals gives up the lock and the waiting thread gets the lock. When the thread that was waiting and is now executing exits or waits again, it releases the lock back to the signaling thread. CS377: Operating Systems

Clicker Question #2 What if we used Hoare monitors instead? (A) Always works fine (B) Remove may sleep forever (C) Items get duplicated (D) remove and return may get run on an empty queue public void synchronized Add( Object item ) { put item on queue; notify (); public Object synchronized Remove() { if queue is empty wait (); // give up lock and go to sleep remove and return item;

Answer on Next Slide

In Class Exercise Build semaphores using monitors (Java)

Semaphores Using Monitors public synchronized sem_signal(){ value++ notify(); public synchronized sem_wait(){ while (value == 0) wait(); value -= 1; You can also implement monitors w/semaphores, but it is tricky

Monitors in C++ Monitors in C++ are more complicated. No synchronization keyword => The class must explicitly provide the lock, acquire and release it correctly Most portable library for threads is pthreads c++11 also provides std:thread+mutex+condition_variable (quickly catching up to pthreads) CS377: Operating Systems

Monitors in C++: Example class Queue { public: Add(); Remove(); private: pthread_cond_t cv; pthread_mutex_t mutex; // cv and mutex must be initialized // queue data(); Queue::Add() { pthread_mutex_lock(&mutex); put item on queue; // ok to access shared data pthread_cond_signal(&cv); pthread_mutex_unlock(&mutex); Queue::Remove() { pthread_mutex_lock(&mutex); while queue is empty pthread_cond_wait(&cv,&mutex) remove item from queue; pthread_mutex_unlock(&mutex); return item; CS377: Operating Systems

What about broadcast? We have only shown the use of signal thus far What happens if you replace signal with broadcast in the previous examples? There may be good reasons to use broadcast, consider the case of a memory allocator

Covering Conditions Assume bytesleft = 0. Then one thread allocate(100), another allocate(10). Then another thread free(50), which should it signal? // how many bytes of the heap are free? int bytesleft = MAX_HEAP_SIZE; // need lock and condition too cond_t c; mutex_t m; void * allocate(int size) { Pthread_mutex_lock(&m); while (bytesleft < size) Pthread_cond_wait(&c, &m); void *ptr = ; bytesleft -= size; Pthread_mutex_unlock(&m); return ptr; void free(void *ptr, int size) { Pthread_mutex_lock(&m); bytesleft += size; Pthread_cond_signal(&c); Pthread_mutex_unlock(&m);

Summary Monitor wraps operations with a mutex Condition variables release mutex temporarily Java has monitors built into the language C++ does not provide a monitor construct, but monitors can be implemented by following the monitor rules for acquiring and releasing locks It is possible to implement semaphores w/monitors and vice versa CS377: Operating Systems