Tutorial 3 Sync or sink! presented by: Antonio Maiorano Paul Di Marco.

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.
Chapter 7 - Resource Access Protocols (Critical Sections) Protocols: No Preemptions During Critical Sections Once a job enters a critical section, it cannot.
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.
1 C OMP 346 – W INTER 2015 Tutorial # 5. Semaphores for Barrier Sync A barrier is a type of synchronization method. A barrier for a group of threads or.
Ch 7 B.
CS Lecture 4 Programming with Posix Threads and Java Threads George Mason University Fall 2009.
May 23, 2002Serguei A. Mokhov, 1 Synchronization COMP346/ Operating Systems Tutorial 3 Revision 1.2 October 7, 2003.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Chapter 6: Process Synchronization
Background Concurrent access to shared data can lead to inconsistencies Maintaining data consistency among cooperating processes is critical What is wrong.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
1 Operating Systems, 122 Practical Session 5, Synchronization 1.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
Secure Operating Systems Lesson 5: Shared Objects.
Intertask Communication and Synchronization In this context, the terms “task” and “process” are used interchangeably.
1 CS318 Project #3 Preemptive Kernel. 2 Continuing from Project 2 Project 2 involved: Context Switch Stack Manipulation Saving State Moving between threads,
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
Semaphores. Announcements No CS 415 Section this Friday Tom Roeder will hold office hours Homework 2 is due today.
Semaphores CSCI 444/544 Operating Systems Fall 2008.
02/17/2010CSCI 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.
Tutorial 2 Adventures in Threading presented by: Antonio Maiorano Paul Di Marco.
More Synchronisation Last time: bounded buffer, readers-writers, dining philosophers Today: sleeping barber, monitors.
CS510 Concurrent Systems Introduction to Concurrency.
Semaphores and Bounded Buffer Andy Wang Operating Systems COP 4610 / CGS 5765.
Object Oriented Analysis & Design SDL Threads. Contents 2  Processes  Thread Concepts  Creating threads  Critical sections  Synchronizing threads.
Tutorial 5 Even More Synchronization! presented by: Antonio Maiorano Paul Di Marco.
© 2004, D. J. Foreman 1 High Level Synchronization and Inter-Process Communication.
Concurrent Programming. Concurrency  Concurrency means for a program to have multiple paths of execution running at (almost) the same time. Examples:
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.
Process Synchronization I Nov 27, 2007 CPE Operating Systems
1 Using Semaphores CS 241 March 14, 2012 University of Illinois Slides adapted in part from material accompanying Bryant & O’Hallaron, “Computer Systems:
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Synchronization Producer/Consumer Problem. Synchronization - PC with Semaphores2 Abstract The producer/consumer problem is a classical synchronization.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
1 Condition Variables CS 241 Prof. Brighten Godfrey March 16, 2012 University of Illinois.
U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Synchronization Emery Berger and Mark Corner University.
Lecture 3 Concurrency and Thread Synchronization     Mutual Exclusion         Dekker's Algorithm         Lamport's Bakery Algorithm.
June 11, 2002Serguei A. Mokhov, 1 The Monitor COMP346 - Operating Systems Tutorial 7 Edition 1.2, June 15, 2002.
CS510 Concurrent Systems Jonathan Walpole. Introduction to Concurrency.
© 2004, D. J. Foreman 1 Monitors and Inter-Process Communication.
© 2004, D. J. Foreman 1 Monitors and Inter-Process Communication.
3/17/2016cse synchronization-p2 © Perkins, DW Johnson and University of Washington1 Synchronization Part 2 CSE 410, Spring 2008 Computer.
Process Synchronization I CPE Operating Systems
Homework-6 Questions : 2,10,15,22.
pThread synchronization
Deadlock and Starvation
Process Synchronization: Semaphores
Background on the need for Synchronization
Process Synchronization
COEN346 Tutorial Monitor Objects.
Monitors.
CSE451 Basic Synchronization Spring 2001
Thread synchronization
Semaphore Originally called P() and V() wait (S) { while S <= 0
Synchronization Hank Levy 1.
Thread Synchronization including Mutual Exclusion
Synchronization Hank Levy 1.
CSE 153 Design of Operating Systems Winter 19
CSE 153 Design of Operating Systems Winter 2019
CS333 Intro to Operating Systems
Process Synchronization
CIS 720 Lecture 6.
CSE 451 Section 1/27/2000.
Process Synchronization
Monitors and Inter-Process Communication
Presentation transcript:

Tutorial 3 Sync or sink! presented by: Antonio Maiorano Paul Di Marco

Whats the problem? Example –A cup of coffee –A pourer (producer) –A drinker (consumer) Result: A mess! Drinker(s): while (true){ drink(); } Pourer: while (true){ pour(); }

So, what do we want? Simple protocol: Pourer pours only when cup is empty Drinker drinks only when cup is full Pourer: while (true){ if (!full){ pour(); full = true; } Drinker(s): while (true){ if (full) { drink(); full = false; }

Ok, but… … what if we have two drinkers? Both drinkers can drink at the same time! Drinker 2: while (true){ if (full) { drink(); full = false; } Drinker 1: while (true){ if (full) { drink(); full = false; } Need this to be atomic!

Fine! So how can we do this? Use Semaphores! A semaphore is an object used to synchronize multiple threads. Two functions: –Wait() : willing –Signal() : release the lock Both functions are guaranteed to be atomic

Semaphore Example Clients arriving at a restaurant with only 10 seats. Manager = Semaphore Clients = Threads 10 Seats = 10 Limited resources controlled using the semaphore.

Semaphore Java Code class Semaphore { private int value; Semaphore (int value1) { value = value1; } public synchronized void Wait () { while( value <= 0 ) { try { wait (); } catch (InterruptedException e) { }; } value--; } public synchronized void Signal () { ++value; notify (); }

Using semaphores, we can make sure that only one drinker can ever drink at one time Important: Wait() and Signal() are guaranteed to be atomic! Multiple drinkers? No problem! Drinker i: while (true){ sem.Wait(); drink(); sem.Signal(); } Main: // Semaphore initialization Semaphore cup; cup = new Semaphore(1);

Programming Assignment 2 Overview of the Problems: 1.The run() of Acquire and Release are not critical sections, hence they could leave Block in an inconsistent internal state 2.Acquires are not to run before the Releases complete

To make matters worse… Not only: 1.are the run() functions not mutually exclusive – yields are inserted to force it to go wrong! 2.must the Acquires wait for the Releases to finish – the Acquires are put on the ready queue first! Ready Queue after all threads are created: main > A1 > A2 > R1 > R2

yield() s at crucial junctures These explicit yield() s represent what could be a time-slice context-switch in a real-world environment ++Block.top; ReleaseBlock : yield (); (push)Block.stack[Block.top] = block ; block = Block.stack[Block.top]; AcquireBlock: yield (); (pop) --Block.top;

Semaphore Initial Values Note that the mutex and semaphores are initialized to different values: The mutex is initialized to one to allow only one thread into the critical section at any time The prisem semaphores are initialized to zero to allow no Acquires to run (initially)

Finally - Assignment Solution!!! Yeah right! 1.Use the mutual-exclusion semaphore to make acquire and release atomic 2.Use the two prisem semaphores to enforce the ordering that all ReleaseBlock threads must complete before any AcquireBlock threads can begin.