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.

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.
Ch 7 B.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, 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.
CY2003 Computer Systems Lecture 05 Semaphores - Theory.
6.5 Semaphore Can only be accessed via two indivisible (atomic) operations wait (S) { while S
COSC 3407: Operating Systems Lecture 8: Semaphores, Monitors and Condition Variables.
Dining-Philosophers Problem Shared data fork[5]: semaphore; initialized to 1.
Classic Synchronization Problems
Classical Problems of Concurrency
02/19/2010CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
Review: Producer-Consumer using Semaphores #define N 100// number of slots in the buffer Semaphore mutex = 1;// controls access to critical region Semaphore.
Chapter 6: Process Synchronization. Outline Background Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems.
1 CS 333 Introduction to Operating Systems Class 5 – Classical IPC Problems Jonathan Walpole Computer Science Portland State University.
Process Synchronization
Monitors CSCI 444/544 Operating Systems Fall 2008.
Semaphores CSCI 444/544 Operating Systems Fall 2008.
02/25/2004CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Module 6: Process Synchronization.
Computer Science 162 Discussion Section Week 3. Agenda Project 1 released! Locks, Semaphores, and condition variables Producer-consumer – Example (locks,
More Synchronisation Last time: bounded buffer, readers-writers, dining philosophers Today: sleeping barber, monitors.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Background Concurrent.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Classical problems.
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 CMPSC 473 Mutual Exclusion Lecture 14: October 14, 2010 Instructor: Bhuvan Urgaonkar.
Synchronization II: CPE Operating Systems
Midterm 1 – Wednesday, June 4  Chapters 1-3: understand material as it relates to concepts covered  Chapter 4 - Processes: 4.1 Process Concept 4.2 Process.
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.
1 Interprocess Communication (IPC) - Outline Problem: Race condition Solution: Mutual exclusion –Disabling interrupts; –Lock variables; –Strict alternation.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Synchronization.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Background The.
13/03/07Week 21 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:
Problems with Semaphores Used for 2 independent purposes –Mutual exclusion –Condition synchronization Hard to get right –Small mistake easily leads to.
Synchronisation Examples
CSC 360 Instructor: Kui Wu More on Process Synchronization Semaphore, Monitor, Condition Variables.
6.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Module 6: Process Synchronization.
ITEC 502 컴퓨터 시스템 및 실습 Chapter 3-3: Process Synchronization Mi-Jung Choi DPNM Lab. Dept. of CSE, POSTECH.
Process Synchronization CS 360. Slide 2 CS 360, WSU Vancouver Process Synchronization Background The Critical-Section Problem Synchronization Hardware.
Dining Philosophers & Monitors Questions answered in this lecture: How to synchronize dining philosophers? What are monitors and condition variables? What.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, Operating System Concepts Operating Systems Lecture 22 Semaphores Classic.
June 11, 2002Serguei A. Mokhov, 1 The Monitor COMP346 - Operating Systems Tutorial 7 Edition 1.2, June 15, 2002.
Chapter 6 Synchronization Dr. Yingwu Zhu. The Problem with Concurrent Execution Concurrent processes (& threads) often access shared data and resources.
6.1 Silberschatz, Galvin and Gagne ©2005 Operating System Principles 6.5 Semaphore Less complicated than the hardware-based solutions Semaphore S – integer.
Deadlock and Starvation
CS703 - Advanced Operating Systems
Dining Philosophers Five philosophers sit around a table
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
Auburn University COMP 3500 Introduction to Operating Systems Synchronization: Part 4 Classical Synchronization Problems.
Chapter 5: Process Synchronization
Deadlock and Starvation
Chapter 6-7: Process Synchronization
Chapter 6: Process Synchronization
CSCI 511 Operating Systems Chapter 5 (Part C) Monitor
Chapter 5: Process Synchronization (Con’t)
Lecture 25 Syed Mansoor Sarwar
Semaphore Originally called P() and V() wait (S) { while S <= 0
Critical section problem
Chapter 7: Synchronization Examples
CSE 451: Operating Systems Autumn Lecture 8 Semaphores and Monitors
CSE 451: Operating Systems Autumn Lecture 7 Semaphores and Monitors
CSE 153 Design of Operating Systems Winter 2019
Synchronization CSE 2431: Introduction to Operating Systems
Presentation transcript:

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 :!QUIT ^[zz ^[ZZ ZZZZ ^H ^L ^[c $q ^# ^E ^X ^I ^T ? help helpquit ^D ^d ^C ^c help ^]q exit ?Quit ?q \qy \xyy F.M.H.! YMHAOS KA9AHQ " - Ed Wright (0x0E2 UNIX The saga Never Ends)

2 Wait and Signal Example P1: S  Wait(); S  Signal(); P2: S  Wait(); S  Signal();

3 Wait and Signal Example P1: S  Wait(); P2: S  Wait(); P1: S  Wait(); P2: S  Signal(); P1: S  Signal(); ValueQueueP1P2 2emptyexecute

4 Wait and Signal Example P1: S  Wait(); P2: S  Wait(); P1: S  Wait(); P2: S  Signal(); P1: S  Signal(); ValueQueueP1P2 2emptyBlock 1YNN 0YNN P1YN 0YNN 1YNN 2YNN

5 Can implement thread join (or Unix system call waitpid) with semaphores Semaphore S=0; Thread::Join S  Wait(); Thread::Finish S  Signal();

6 Semaphores can be used for three purposes: §To ensure mutual exclusion of a critical section (as locks) §To control access to a shared pool of resources (using counting semaphore) §To cause a thread/process to wait for a specific action to be signaled by another thread/process

7 Reader Process wait(mutex); readcount++; if (readcount == 1) wait(wrt); signal(mutex); … reading is performed … wait(mutex); readcount--; if (readcount == 0) signal(wrt); signal(mutex); A couple of questions: 1.If a wrier is in Critical section and two readers arrive, where does the first one block and where does the second one block? 2.Why do we use a single mutex here?

8 Dining-Philosophers Problem §There are 5 philosophers sitting at a round table. Between each adjacent pair of philosophers is a chopstick. In other words, there are five chopsticks. §Each philosopher does two things: think and eat. §The philosopher thinks for a while, and then stops thinking and becomes hungry. §When the philosopher becomes hungry, he/she cannot eat until he/she owns the chopsticks to his/her left and right. §When the philosopher is done eating he/she puts down the chopsticks and begins thinking again.

9 Dining-Philosophers Problem §Shared data semaphore chopstick[5]; Initially all values are 1 Allocate several resources among processes in deadlock-free, starvation-free manner

10 §The philosophers basically go through the following steps. while(1) { think for a random number of seconds pickup forks; eat for a random number of seconds putdown forks; }

11 Dining-Philosophers Problem §Philosopher i: do { wait(chopstick[i]) wait(chopstick[(i+1) % 5]) … eat … signal(chopstick[i]); signal(chopstick[(i+1) % 5]); … think … } while (1);

12 Dining Philosopher - Deadlock Free Solution state[] array is initialized to THINKING semaphore array s[i], i=0 … N-1, is initialized to zero

13 Dining Philosopher - Deadlock Free Solution

14 Dining Philosopher - Deadlock Free Solution void take_forks(int i) { wait(mutex); state[i]=HUNGRY; test(i); signal(mutex); wait(s[i]); }

15 Dining Philosopher - Deadlock Free Solution void test(i) {// i is philosopher number if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) { state[i]=EATING; signal (s[i]); }

16 Dining Philosopher - Deadlock Free Solution void put_forks(i) { wait(mutex); state[i]=THINKING; test(LEFT); test(RIGHT); signal(mutex); }

17 Sleeping Barber Problem

18 Sleeping Barber Problem Barber shop has one barber and n chairs If no customers are present, the barber sleeps When customer arrives, he has to wake up the sleeping barber If additional customer arrives while the barber is cutting another’s hair then: he sits down and waits if empty chairs available he leaves if all chairs are full

19 Sleeping Barber Problem Customer /*check if chair available, if not leave*/ /**signal that I have arrived**/ /*wait until barber cuts my hair */ } Barber /*sleep until customer wakes me up*/ /* service customer (remember to update chairs available) */ /* tell customer to leave*/ /*repeat the above for other customers*/

20 Sleeping Barber Problem N = 5; //number of chairs int chairs_occupied = 0; semaphore mutex = 1;

21 Sleeping Barber Problem N = 5; //number of chairs int chairs_occupied = 0; semaphore mutex = 1; semaphore barber_finished = 0; semaphore customer_arrived = 0;

22 Sleeping Barber Problem Customer{ wait(mutex); if (chairs_occupied<num) chairs_occupied ++; else{ signal(mutex); exit(); } signal(mutex); signal(customer_arrived) wait(barber_finished); } Barber{ while(true){ wait(customer_arrived); wait(mutex); chairs_occupied --; signal(mutex); cut_hair( ); signal(barber_finished); }

23 Another example §Motorbike assembly §One process makes tyres §Another process makes chassis and assembles motorbike §Tyre processes and chassis process should exit when a motorbike is complete Barrier

24 Motorbike assembly MakeTyres /* signal when tyre is ready */ /* wait until tyre is assembled in a motorbike */ MakeChassis&Assemble /*make chassis */ /*wait for both tyres to arrive*/ /*assemble motorbike*/ /*tell both tyres that they have been used*/

25 What happens here? MakeTyreFunction( ){ signal(tyre); wait(motorbike_done); } MakeChassis&Assemble( ){ /*make chassis */ wait(tyre); /* assemble motorbike*/ signal(motorbike_done); } semaphore tyre = 0; semaphore motorbike_done = 0;

26 This solution is incorrect MakeTyreFunction( ){ signal(tyre); wait(motorbike_done); } MakeChassis&Assemble( ){ wait(tyre); /*make chassis and assemble motorbike*/ signal(motorbike_done); } semaphore tyre = 0; semaphore motorbike_done = 0;

27 Another possible solution (incomplete)... MakeTyreFunction( ){ wait(mutex); count++; if (count = = 2){ signal(assemble); signal(tyre_exit); count = 0;} signal(mutex); wait(tyre_exit); } MakeChassis&Assemble( ){ wait(assemble); /*make chassis and assemble motorbike*/ } semaphore tyre_exit = 0; semaphore chassis_arrived = 0; semaphore assemble = 0;

28 Another possible solution (complete) MakeTyreFunction( ){ wait(chassis_arrived); wait(mutex); count++; if (count = = 2){ signal(assemble); signal(tyre_exit); count = 0;} signal(mutex); wait(tyre_exit); } MakeChassis&Assemble( ){ signal(chassis_arrived); wait(assemble); /*make chassis and assemble motorbike*/ } semaphore tyre_exit = 0; semaphore chassis_arrived = 0; semaphore assemble = 0;

29 Semaphore l Essentially shared global variables. l No control or guarantee of proper usage. Solution l Use a higher level primitive called monitors.

30 Monitors §Higher level synchronization primitive. §Similar to a C++ class that ties data, operations together. §Processes may call the procedures in a monitor whenever they want to, but cannot access the private data structures from functions outside the monitor.

31 Monitors Unlike classes: l Monitors ensure mutual exclusion Only one thread may execute a given monitor method at a time. l Monitors require all data to be private.

32 Monitors

33 Schematic View of a Monitor

34 Monitors §Only one process can be active in a monitor at any instant. §Monitors are programming level constructs, so compiler knows they are special and can handle calls to monitor procedures differently. §Compiler implements the mutual exclusion on monitor. §Programmer does not have to be aware of how the compiler arranges for mutual exclusion.

35 Monitors §Turn critical regions into monitor procedures, no two processes shall execute their critical regions at same time.

36 Monitors §The Java synchronized construct implements a limited form of monitor §It is simple to turn a Java class into a monitor l Make all data private l Make all methods synchronized

37 class Queue{ 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; }

38 How can we change remove() to wait until something is on the queue? §Logically, we want to go to sleep inside of the monitor. § 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. §The thread could sleep forever.

39 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.

40 Condition variable: is a queue of threads waiting for something inside a critical section. Condition variables support three operations: 1.Wait(): 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.

41 Monitor With Condition Variables

42 In Java: §The wait() method causes a thread to release the lock it is holding on an object; allowing another thread to run l wait() can only be invoked from within synchronized code §Use notify() to signal that the condition a thread is waiting on is satisfied. §Use notifyAll() to wake up all waiting threads. l notify() and notifyAll() can only be used within synchronized code

43 In Java class Queue { private...; // queue data } 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; }

44 Monitors §Condition variables are not counters §They do not accumulate signals like semaphores do §Condition variable is signaled with no process waiting, signal is lost.

45 Monitors How is this different from sleep and wakeup we saw earlier?

46 Monitors

47 Monitor Operations §Encapsulates shared data you want to protect. §Acquires mutex at the start. §Operations on shared data. §Temporarily releases mutex if it can’t complete. §Re-acquires mutex when it can continue. §Releases mutex at the end.

48 Mesa-style: (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.