– R 7 :: 1 – 0024 Spring 2010 Parallel Programming 0024 Recitation Week 7 Spring Semester 2010.

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.
Ken Birman 1. Refresher: Dekers Algorithm Assumes two threads, numbered 0 and 1 CSEnter(int i) { int J = i^1; inside[i] = true; turn = J; while(inside[J]
More on Semaphores, and Classic Synchronization Problems CSCI 3753 Operating Systems Spring 2005 Prof. Rick Han.
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
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo.
Concurrency: monitors & condition synchronization1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 8b Monitors.
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.
Threading Part 4 CS221 – 4/27/09. The Final Date: 5/7 Time: 6pm Duration: 1hr 50mins Location: EPS 103 Bring: 1 sheet of paper, filled both sides with.
Enforcing Mutual Exclusion, Semaphores. Four different approaches Hardware support Disable interrupts Special instructions Software-defined approaches.
© Andy Wellings, 2004 Roadmap  Introduction  Concurrent Programming  Communication and Synchronization  Completing the Java Model  Overview of the.
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.
Chapter 6: Process Synchronization. Outline Background Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems.
Semaphores 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.
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.
02/19/2007CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
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.
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.
Semaphores, Locks and Monitors By Samah Ibrahim And Dena Missak.
4061 Session 21 (4/3). Today Thread Synchronization –Condition Variables –Monitors –Read-Write Locks.
CSC321 Concurrent Programming: §5 Monitors 1 Section 5 Monitors.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization.
OPERATING SYSTEMS Frans Sanen.  Recap of threads in Java  Learn to think about synchronization problems in Java  Solve synchronization problems in.
In Java processes are called threads. Additional threads are associated with objects. An application is associated with an initial thread via a static.
Advanced Concurrency Topics Nelson Padua-Perez Bill Pugh Department of Computer Science University of Maryland, College Park.
1 CMSC421: Principles of Operating Systems Nilanjan Banerjee Principles of Operating Systems Acknowledgments: Some of the slides are adapted from Prof.
Monitors and Blocking Synchronization Dalia Cohn Alperovich Based on “The Art of Multiprocessor Programming” by Herlihy & Shavit, chapter 8.
1 Condition Variables CS 241 Prof. Brighten Godfrey March 16, 2012 University of Illinois.
Java Producer-Consumer Monitor From: Concurrent Programming: The Java Programming Language By Steven J. Hartley Oxford University Press, 1998.
13/03/07Week 21 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:
Lecture 6: Monitors & Semaphores. Monitor Contains data and procedures needed to allocate shared resources Accessible only within the monitor No way for.
Comunication&Synchronization threads 1 Programación Concurrente Benemérita Universidad Autónoma de Puebla Facultad de Ciencias de la Computación Comunicación.
Synchronization CSCI 3753 Operating Systems Spring 2005 Prof. Rick Han.
Process Synchronization CS 360. Slide 2 CS 360, WSU Vancouver Process Synchronization Background The Critical-Section Problem Synchronization Hardware.
June 11, 2002Serguei A. Mokhov, 1 The Monitor COMP346 - Operating Systems Tutorial 7 Edition 1.2, June 15, 2002.
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.
3/17/2016cse synchronization-p2 © Perkins, DW Johnson and University of Washington1 Synchronization Part 2 CSE 410, Spring 2008 Computer.
pThread synchronization
Race Conditions & Synchronization
CS703 – Advanced Operating Systems
COT 4600 Operating Systems Fall 2009
PARALLEL PROGRAM CHALLENGES
Background on the need for Synchronization
Java Concurrency.
Lecture 25 More Synchronized Data and Producer/Consumer Relationship
Operating Systems CMPSC 473
Monitors Chapter 7.
Semaphore Originally called P() and V() wait (S) { while S <= 0
Background Concurrent access to shared data can lead to inconsistencies Maintaining data consistency among cooperating processes is critical What is wrong.
Semaphores Chapter 6.
Monitors Chapter 7.
CSE 451: Operating Systems Autumn Lecture 8 Semaphores and Monitors
Monitors Chapter 7.
Monitor Giving credit where it is due:
Thread Synchronization including Mutual Exclusion
CSE 153 Design of Operating Systems Winter 19
CSE 153 Design of Operating Systems Winter 2019
EECE.4810/EECE.5730 Operating Systems
CSE 542: Operating Systems
Presentation transcript:

– R 7 :: 1 – 0024 Spring 2010 Parallel Programming 0024 Recitation Week 7 Spring Semester 2010

– R 7 :: 2 – 0024 Spring 2010 Today‘s program Assignment 6 Review of semaphores Semaphores Semaphoren and (Java) monitors Semaphore implementation of monitors (review) Assignment 7

– R 7 :: 3 – 0024 Spring 2010 Semaphores Special Integer variable w/2 atomic operations P()(Passeren, wait/up) V()(Vrijgeven/Verhogen, signal/down) Names of operations reflect the Dutch origin of the inventor...

– R 7 :: 4 – 0024 Spring 2010 class Semaphore public class Semaphore { private int value; private int value; public Semaphore() { public Semaphore() { value = 0; } public Semaphore(int k) { public Semaphore(int k) { value = k; } public synchronized void P() { /* see next slide */ } public synchronized void P() { /* see next slide */ } public synchronized void V() { /* see next slide */ } public synchronized void V() { /* see next slide */ }}

– R 7 :: 5 – 0024 Spring 2010 P() operation public synchronized void P() { while (value == 0) { while (value == 0) { try { try { wait(); wait(); } catch (InterruptedException e) { } catch (InterruptedException e) { } } value --; value --; }

– R 7 :: 6 – 0024 Spring 2010 V() operation public synchronized void V() { ++value; ++value; notifyAll(); notifyAll(); }

– R 7 :: 7 – 0024 Spring 2010 Comments You can modify the value of an semphore instance only using the P() and V() operations. Initialize in constructorEffect P() may block V() never blocks Application of semaphores: Mutual exclusion Conditional synchronization

– R 7 :: 8 – 0024 Spring kinds of semaphores Binary semaphore Value is either 0 or 1 Supports implemention of mutual exclusion Semaphore s = new Semaphore(1); s.p() //critical section s.v() Counting (general) semaphore Value can be any positive integer value

– R 7 :: 9 – 0024 Spring 2010 Fairness A semaphore is considered to be “fair“ if all threads that execute a P() operation eventually succeed. Different models of fairness – Semaphore is “unfair”: a thread blocked in the P() operation must wait forever while other threads (that executed the operation later) succeed.

– R 7 :: 10 – 0024 Spring 2010 Semaphores in Java java.util.concurrent.Semaphore java.util.concurrent.Semaphore acquire() instead of P() acquire() instead of P() release() instead of V() release() instead of V()Constructors Semaphore(int permits); Semaphore(int permits); Semaphore(int permits, boolean fair); Semaphore(int permits, boolean fair); permits: initial value fair: if true then the semphore uses a FIFO to manage blocked threads

– R 7 :: 11 – 0024 Spring 2010 Semaphores and monitors Monitor: model for synchronized methods in Java Both constructs are equivalent One can be used to implement the other

– R 7 :: 12 – 0024 Spring 2010 Example from Mar 18 See slides for context

– R 7 :: 13 – 0024 Spring 2010 Buffer using condition queues class BoundedBuffer extends Buffer { public BoundedBuffer(int size) { super(size); } public synchronized void insert(Object o) throws InterruptedException { while (isFull()) wait(); doInsert(o); notifyAll(); }// insert

– R 7 :: 14 – 0024 Spring 2010 Buffer using condition queues, continued // in class BoundedBuffer public synchronized Object extract() throws InterruptedException { while (isEmpty()) wait(); Object o = doExtract(); notifyAll(); return o; }// extract } // BoundedBuffer

– R 7 :: 15 – 0024 Spring 2010 Emulation of monitor w/ semaphores We need 2 semaphores: One to make sure that only one synchronized method executes at any tiven time call this the “access semaphore” (S) binary semaphore One semaphore to line up threads that are waiting for some condition call this the “condition semaphore” (SCond) – also binary call this the “condition semaphore” (SCond) – also binary threads that wait must do an “acquire” and this will not complete For convenience: Counter waitThread to count number of waiting threads i.e., threads in queue for SCond

– R 7 :: 16 – 0024 Spring 2010 Basic idea  Frame all synchronized methods with S.acquire() and S.release() This ensures that only one thread executes a synchronized method at any point in time Recall S is binary.  Translate wait() and notifyAll() to give threads waiting in line a chance to progress (these threads use SCond) To simplify the debate, we require that “notifyAll()” is the last action in a synchronized method Java does not enforce this requirement but the mapping of synchronized methods into semaphores is simplified.

– R 7 :: 17 – 0024 Spring 2010 Buffer with auxiliary fields class BoundedBuffer extends Buffer { public BoundedBuffer(int size) { super(size); access = new Semaphore(1); cond = new Semaphore(0); } private Semaphore access; private Semaphore cond; private int waitThread = 0; // continued

– R 7 :: 18 – 0024 Spring ) Framing all methods public void insert(Object o) throws InterruptedException { access.acquire(); //ensure mutual exclusion while (isFull()) wait(); doInsert(o); notifyAll(); access.release(); }// insert

– R 7 :: 19 – 0024 Spring 2010 Notes There is one semaphore for all synchronized methods of one instance of “BoundedBuffer” Why? Must make sure that insert and extract don’t overlap. There must be separate semaphore to deal with waiting threads. Why? Imagine the buffer is full. A thread that attempts to insert an item must wait. But it must release the access semaphore. Otherwise a thread that wants to remove an item will not be able to executed the (synchronized!) extract method.

– R 7 :: 20 – 0024 Spring ) Translate wait and notifyAll The operation wait() is translated into waitThread ++ S.release(); // other threads can execute synchronized methods SCond.acquire(); // wait until condition changes S.acquire(); waitThread --

– R 7 :: 21 – 0024 Spring 2010 Each occurrrence of NotifyAll() is translated if (waitThread > 0) { if (waitThread > 0) { for (int i=0; i< waitThread; i++) { SCond.release();} } All threads waiting are released and will compete to (re)acquire S. They decrement waitThread after they leave SCond.acquire Note that to enter the line (i.e., increment waitThread) the thread must hold the access semaphore S

– R 7 :: 22 – 0024 Spring 2010 Recall that S.release is done at the end of the synchronized method So all the threads that had lined up waiting for SCond compete to get access to S No thread can line up while the SCond.release operations are done since this thread holds S.

– R 7 :: 23 – 0024 Spring 2010 Note We wake up only all threads – they might not be able to enter their critical section if the condition they waited for does not hold. But all threads get a chance. This approach is different from what we discussed in the lecture

– R 7 :: 24 – 0024 Spring 2010 Translate “wait()” public void insert(Object o) throws InterruptedException { access.acquire(); while (isFull()) { waitThread ++; access.release(); // let other thread access object cond.acquire(); // wait for change of state access.acquire() waitThread --; } doInsert(o); notifyAll(); access.release(); }// insert

– R 7 :: 25 – 0024 Spring 2010 Translate “notifyAll()” public void insert(Object o) throws InterruptedException { access.acquire(); while (isFull()) { waitThread ++; access.release(); // let other thread access object cond.acquire(); // wait for change of state access.acquire() waitThread --; } doInsert(o); if (waitThread > 0) { for (int i=0; i<waitThread; i++) { cond.release(); } } access.release(); }// insert

– R 7 :: 26 – 0024 Spring 2010 Example Consider the buffer, one slot is empty, four operations insert I1 insert I2 extract E extract E I1 – access.acquire I2 – access.acquire: blocks on access I3 – access.acquire: blocks on access I1 – waitThread == 0 I1.release

– R 7 :: 27 – 0024 Spring 2010 (cont) I2 – access.acquire completes I2 – access.acquire completes I2 – buffer full waitThread =1 I2 – access.release I2 – cond.acquire – blocks on cond I3 – access.acquire completes I3 – buffer full waitThread = 2 I3 – access.release I3 – cond.acquire – blocks on cond

– R 7 :: 28 – 0024 Spring 2010 (cont) E – access.acquire E – access.acquire remove item remove item E – SCond.release E – SCond.release E – access.release E – access.release One of I2 or I3 will succeed with access.acquire and be able to insert the next item

– R 7 :: 29 – 0024 Spring 2010 Exercise How would the method “extract” look like (if we used semaphores to emulate monitors)?

– R 7 :: 30 – 0024 Spring 2010 Assignment 7 Hint: Thread.currentThread() returns a handle to the current thread and might be useful for the assignment.

– R 7 :: 31 – 0024 Spring 2010 Overview Your task is to implement a Read/Write Lock Max. 4 Threads Max. 2 Reader Threads (shared access is allowed) and 1 Writer Thread A thread that executes read() is a reader At a later time it can be a writer....

– R 7 :: 32 – 0024 Spring 2010 The challenge No starvation Efficient implementation If there are fewer than 2 readers and no waiting writers then the next reader must be allowed to proceed If there is no contention then a thread must be allowed to proceed immediately Your implementation must be fair (you may want to use FIFOQueue.java)

– R 7 :: 33 – 0024 Spring 2010 Other comments Keep your solution as simple as possible Decide what you want to use [your decision] Monitors (synchronized methods) Semaphores  Semaphore Only change class Monitor.java If you feel it‘s necessary to change other files, please let us know. Please comment your code!

– R 7 :: 34 – 0024 Spring 2010 You may want to recall Thread.currentThread().getId() wait_list.enq(Thread.currentThread().getId()) wait_list.getFirstItem() == Thread.currentThread().getId()

– R 7 :: 35 – 0024 Spring 2010 Your log could look like this … READ LOCK ACQUIRED 1 READ LOCK RELEASED 0 WRITE LOCK ACQUIRED 1 WRITE LOCK RELEASED 0 READ LOCK ACQUIRED 1 READ LOCK ACQUIRED 2 READ LOCK RELEASED 1 READ LOCK ACQUIRED 2 READ LOCK RELEASED 1 READ LOCK ACQUIRED 2