© Janice Regan, CMPT 300, May 2007 0 CMPT 300 Introduction to Operating Systems Classical problems.

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.
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.
Operating Systems Mehdi Naghavi Winter 1385.
1 Chapter 5 Concurrency: Mutual Exclusion and Synchronization Principals of Concurrency Mutual Exclusion: Hardware Support Semaphores Readers/Writers Problem.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Ch 7 B.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
CY2003 Computer Systems Lecture 05 Semaphores - Theory.
6.5 Semaphore Can only be accessed via two indivisible (atomic) operations wait (S) { while S
Classic Synchronization Problems
Informationsteknologi Wednesday, September 26, 2007 Computer Systems/Operating Systems - Class 91 Today’s class Mutual exclusion and synchronization 
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Classical Problems of Concurrency
Chapter 5 Concurrency: Mutual Exclusion and Synchronization
Avishai Wool lecture Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.
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.
Concurrency: Deadlock and Starvation Chapter 6. Revision Describe three necessary conditions for deadlock Which condition is the result of the three necessary.
1 CS 333 Introduction to Operating Systems Class 5 – Classical IPC Problems Jonathan Walpole Computer Science Portland State University.
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.
Concurrency: Mutual Exclusion, Synchronization, Deadlock, and Starvation in Representative Operating Systems.
Process Synchronization
Monitors CSCI 444/544 Operating Systems Fall 2008.
A. Frank - P. Weisberg Operating Systems Introduction to Cooperating Processes.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
Adopted from and based on Textbook: Operating System Concepts – 8th Edition, by Silberschatz, Galvin and Gagne Updated and Modified by Dr. Abdullah Basuhail,
More Synchronisation Last time: bounded buffer, readers-writers, dining philosophers Today: sleeping barber, monitors.
Condition Variables Revisited Copyright ©: University of Illinois CS 241 Staff1.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Introduction to Concurrency.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion.
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.
Critical Problem Revisit. Critical Sections Mutual exclusion Only one process can be in the critical section at a time Without mutual exclusion, results.
Operating Systems CMPSC 473 Mutual Exclusion Lecture 14: October 14, 2010 Instructor: Bhuvan Urgaonkar.
Thread Synchronization Tutorial #8 CPSC 261. A thread is a virtual processor Each thread is provided the illusion that it owns a core – Copy of the registers.
Chap 6 Synchronization. Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
1 Interprocess Communication (IPC) - Outline Problem: Race condition Solution: Mutual exclusion –Disabling interrupts; –Lock variables; –Strict alternation.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Background The.
Synchronisation Examples
Semaphores Ref: William Stallings G.Anuradha. Principle of a Semaphore Two or more processes can cooperate by means of simple signals, such that a process.
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.
1 Processes and Threads Part II Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
Producer-Consumer Problem David Monismith cs550 Operating Systems.
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.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion Mutexes, Semaphores.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems The producer consumer problem Monitors and messaging.
Interprocess Communication Race Conditions
Dining Philosophers Five philosophers sit around a table
Auburn University COMP 3500 Introduction to Operating Systems Synchronization: Part 4 Classical Synchronization Problems.
Background on the need for Synchronization
Chapter 5: Process Synchronization – Part II
2.4 Classic IPC Problems Dining philosophers Readers and writers
Ref: William Stallings,Galvin, Naresh Chauhan G.Anuradha
Chapter 5: Process Synchronization (Con’t)
Chapter 5: Process Synchronization
Lecture 25 Syed Mansoor Sarwar
Process Synchronization
Critical section problem
Concurrency: Mutual Exclusion and Process Synchronization
More IPC B.Ramamurthy 4/15/2019.
“The Little Book on Semaphores” Allen B. Downey
CSE 542: Operating Systems
CSE 542: Operating Systems
Presentation transcript:

© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Classical problems

© Janice Regan, CMPT 300, May The producer consumer problem  Shares a limited resource, for example an input or output buffer, that may contain one or more storage locations  Basic idea:  a consumer that uses data (puts it in the buffer)  a consumer that uses that data (takes it out of the buffer)  Allow the two to collaborate using one of our mutual exclusion methods

© Janice Regan, CMPT 300, May The dining philosophers  N philosophers sitting at a round table for a meal  Each has a plate of food  Each needs two forks to eat  There is one fork between each two plates (analogous to resource sharing in a computer system)

© Janice Regan, CMPT 300, May Dining philosophers

© Janice Regan, CMPT 300, May Dining Philospher  Simplest attempt void philosopher( ) { While( 1 ) { think(); takeLeftFork(); takeRightFork(); eat( ); releaseLeftFork( ); releaseRightFork( ); } takeLeftFork() and takeRightFork() both check to see if the fork is available and block if it is not

A more general solution © Janice Regan, CMPT 300, May void philosopher( i ) { while( 1 ) { think(); semWait((i+1)%N); semWait(i); eat( ); semSignal((i+1)%N); semSignal(i); }

© Janice Regan, CMPT 300, May Problems  If all philosophers think and eat with equal speed deadlock occurs  Try other approaches.  If one fork is blocked and the philosopher has the other then put down the one that has already been picked up: can lead to starvation  Try waiting a random length of time between picking up forks. Works most of the time, but particular conditions will still lead to deadlock or starvation

Use one semaphore  If we use a semaphore so that only one philosopher can pick up a fork at any one time we can solve the problem  This is not an optimal solution since it should be possible for two philosphers to eat at the same time (there are 5 forks) © Janice Regan, CMPT 300, May

8 Dining Philospher void philosopher( ) { While( 1 ) { think(); mutexWait(eat) takeLeftFork(); takeRightFork(); eat( ); releaseLeftFork( ); releaseRightFork( ); mutexSignal(eat) }

A more general solution © Janice Regan, CMPT 300, May void philosopher( i ) { while( 1 ) { think(); mutexWait(eat) semWait((i+1)%N); semWait(i); eat( ); semSignal((i+1)%N); semSignal(i); mutexSignal(eat) } void philosopher( k) { while( 1 ) { think(); mutexWait(eat) semWait((k+1)%N); semWait(k); eat( ); semSignal((k+1)%N); semSignal(k); mutexSignal(eat) }

© Janice Regan, CMPT 300, May Problems / solution  Approach in text: deadlock free: uses states,(eating, thinking, hungry)  A philosopher thinks until they become hungry  When they become hungry they move from state thinking to state hungry  They may move from state hungry to state eating (begin to eat only) if their neighbors are not eating  When they are finished eating they start to think again (move from state eating to state thinking eatinghungrythinking

© Janice Regan, CMPT 300, May Dining Philosophers #define N=5// number of philosophers #define THINKING=0// states philosopher can be in #define HUNGRY=1 #define EATING=2 semaphore protect = 1;// mutex for mutual exclusion semaphore philosopherState[N]; // array of semaphores // one for each philosopher // could use mutexes // can’t read states from semaphore, put them in variable too int localState[N];// variable holding states

© Janice Regan, CMPT 300, May Dining Philosophers  First think about solving the problem without the complications of concurrency. We will hide those complications inside of our procedures takeForks( ) and releaseForks( ); void philosopher( int i ) { while( true ) { think( );//(state thinking) takeForks( );//acquire forks or block (state hungry) eat( );//(state eating) releaseForks( );//go back to state thinking }

© Janice Regan, CMPT 300, May Dining Philosophers  We want to be able to test if philosopher i can eat now. We will need to test in several places so make a testing procedure  Note: we are not protecting shared variable localState so the execution of this entire procedure must be protected when it is called void test( int i ) { //testing, make sure philospher i is hungry, // make sure philospher i’s neighbors are not eating if( localState[i] == HUNGRY && localState[ (i+1)%N ] != EATING && localState[ (i-1)%N ] != EATING ) { localState[i] = EATING; // philosopher i begins eating semSignal( philosopherState[i] ); }

© Janice Regan, CMPT 300, May Dining Philosophers  Now we want to figure out what goes in the procedure releaseForks( )  Move the philosopher from the eating state to the thinking state  Consider each of the philosopher‘s neighbors in turn. If the neighbor is hungry and can now acquire both their forks, unblock the neighbor (this philosopher was the one blocking) void releaseForks( int i ) { mutexWait( &protect ); localState[i] = THINKING; test((i+1)%N); test((i-1)%N); mutexSignal( &protect ); }

© Janice Regan, CMPT 300, May Dining Philosophers  Now we want to figure out what goes in the procedure takeForks( )  move the philosopher from the thinking state to the hungry state  Try to acquire forks Block if both forks are not available OR Move the philosopher to the eating state if forks are acquired void takeForks( int i ) { mutexWait( &protect ); localState[i] = HUNGRY; test(i); mutexSignal( &protect ); semWait( &philosopherState[i] ) }

© Janice Regan, CMPT 300, May The sleeping barber  Consider a barber shop  There are numBarber barbers each with 1 barber chair  There are numChairs chairs for customers waiting for a haircut  If there are no customers waiting when a barber finishes a haircut the barber falls asleep until a customer arrives and wakes him up  If there are customers waiting when a barber finishes the next customer is woken up and moves from the waiting chair to the barbers chair in preparation for their haircut (problem in synchronizing use of resources)

© Janice Regan, CMPT 300, May The sleeping barber  If all barbers are busy when a customer arrives the customer checks to see if there are any empty chairs in the waiting room  If there are the customer sits in the chair and goes to sleep until a barber is ready to cut their hair  If there are not the customer leaves without a haircut  If a barber is available the arriving customer will wake the barber and sit in his chair in preparation for having their hair cut

© Janice Regan, CMPT 300, May How do we start ?  Need to analyze our problem  A good to for helping in the design of these types of problems is a state diagram  Lets start by making a state diagram for the barber and customer in this problem

© Janice Regan, CMPT 300, May States: Barber  Sleeping: The barber may be sleeping  Idle: The barber may be awake and ready to start a haircut, or may have just finished a haircut and be checking to see if he needs to start another cut or if he can go to sleep  Cutting: The barber may be cutting a customers hair

© Janice Regan, CMPT 300, May State machine for barber IDLE CUTTING SLEEPING New customer arrives for haircut and wakes barber No customers waiting Customer sits in barber’s chair Barber finishes haircut Initial state Final state Barber arrives Barber leaves

© Janice Regan, CMPT 300, May States: Customer  Sleeping: The customer may be sleeping  Idle: The customer may be awake and ready to start thier haircut, they may have just arrived and be checking to see if there is a barber chair or waiting chair available, they may be leaving after their hair has been cut  Having cut: The barber may be cutting a customers hair

© Janice Regan, CMPT 300, May State machine for customer SLEEPING Barber available on arrival Hair cut finished Initial state Final state IDLE Customer arrives Customer leaves HAIR CUT Barbers busy waiting chair available Barber available customers turn

© Janice Regan, CMPT 300, May Semaphore wait operation:  The semWait operation  Decrements the semaphore value  If the value is >=0, the process is allowed to run its critical region  If the value is negative then the process is blocked (put to sleep) and placed in the blocked queue

© Janice Regan, CMPT 300, May Semaphore signal operation:  The semSignal operation  Increments the semaphore value  If the semaphore value is not positive (<=0) the first process in the blocked queue is woken up and placed in the ready queue

© Janice Regan, CMPT 300, May Getting started: semaphores  Need to count the number of customers that are waiting. Use a shared variable waiting protected by a mutex (for mutual exclusion)  Need to assure the number of waiting customers does not exceed the number of waiting chairs  Need to put the barber to sleep is there are no customers. Use a semaphore barber  Need to put the customer to sleep while they are waiting. Use a semaphore customers

© Janice Regan, CMPT 300, May Customer: using semaphores semaphore customers = 0; // counts waiting customers semaphore barbers = 0; // counts number of idle barbers mutex checking = 0; // mutex to protect shared variable waiting int CHAIRS = 8; // number of chairs for waiting int waiting = 0; // need variable too (cannot check value of semaphore) void customer ( ) { mutexWait(&checking); // protect shared variable if(waiting < CHAIRS) { // Is there and available chair waiting++; // increment number waiting semSignal(&customers); // wake up the barber if necessary mutexSignal(&checking); // remove protection on shared semWait(&barbers); // customer goes to sleep if waiting getCut(); } else { mutexSignal(&checking); // no chairs customer leaves }

© Janice Regan, CMPT 300, May Barber: using semaphores semaphore customers = 0; // counts waiting customers semaphore barbers = 0; // counts number of idle barbers mutex checking = 0; // mutex to protect shared variable waiting int CHAIRS = 8; // number of chairs for waiting int waiting = 0; // need variable too (cannot check value of semaphore) void barber ( ) { while (true) { semWait(&customers); //block(barber sleeps) / take next customer mutexWait(&checking); //protect shared counter waiting--;//decrement number of waiting customers semSignal(&barbers); //block(customer sleeps) or proceed to cut mutexSignal(&checking);//remove protection on shared counter cut(); }

© Janice Regan, CMPT 300, May Example 1  First customer arrives before the barber  waiting and customers incremented to 1  barber decremented to -1: customer sleeps  Barber arrives  customers and waiting decremented to 0 (barber does not sleep)  barbers is incremented to 0 (wake customer)  Cut hair

© Janice Regan, CMPT 300, May Example 2  Barber arrives  customer is decremented to -1, barber sleeps  Customer arrives  waiting and customers incremented to 1 and 0 (customer = 0, barber wakes up)  Decrement barber to -1 (customer sleeps)  Barber starts  Decrements waiting  Increments barber to 0 (wakes customer)  Cuts hair

© Janice Regan, CMPT 300, May Readers and writers  Another classic problem that models access to a database  Large file (database) shared by many users  Problem is maintaining data consistency  Cannot allow read access while writing This can cause reading of inconsistent data  For data consistency must satisfy  Only one writer at a time may access the system  If a writer is accessing the file, no reader may access  Any number of readers may access simultaneously

© Janice Regan, CMPT 300, May Readers have priority  Consider multiple readers and writers  Use mutual exclusion to assure exclusive access by writers  Can lead to starvation of writers  wsem is used to enforce mutual exclusion (writers have lone access)  x protects the setting of readcount and wsem (readcount is locally readable wsem)

© Janice Regan, CMPT 300, May Readers have priority int readcount; semaphore x=1, wsem=1; void reader( ) { semWait(x); readcount++; if(readcount == 1) { semWait(wsem); } semSignal(x); readUnit(); semWait(x); readcount --; if(readcount == 0) { semSignal(wsem); } semSignal(x); } void writer( ) { while(true) { semWait(wsem); writeUnit(); semSignal(wsem); } void main( ) { reacount = 0; parbegin(reader, writer); }

© Janice Regan, CMPT 300, May Writers have priority  rsem blocks readers while there is at least one writer  writecount controls the setting of rsem  y protects the updating of writecount

© Janice Regan, CMPT 300, May Writers have priority int readcount; semaphore x=1, y=1, z=1, wsem=1, rsem=1; void reader( ) { semWait(z); semWait(rsem); semWait(x); readcount++; if(readcount == 1) { semWait(wsem); } semSignal(x); semSignal(rsem); semSignal(z); readUnit(); semWait(x); readcount --; if(readcount == 0) { semSignal(wsem); } semSignal(x); } void writer( ) { semWait(y); writecount++; if(writecount – 1) { semWait(wsem); } semSignal(y); writeUnit(); semSignal(wsem); semWait(y); writecount --; if(writecount==0) { semSignal(rsem); } semSignal(y); } void main( ) { reacount = 0; parbegin(reader, writer); }