Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "© Janice Regan, CMPT 300, May 2007 0 CMPT 300 Introduction to Operating Systems Classical problems."— Presentation transcript:

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

2 © Janice Regan, CMPT 300, May 2007 1 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

3 © Janice Regan, CMPT 300, May 2007 2 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)

4 © Janice Regan, CMPT 300, May 2007 3 Dining philosophers 4 3 0 2 1 0 3 4 1

5 © Janice Regan, CMPT 300, May 2007 4 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

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

7 © Janice Regan, CMPT 300, May 2007 6 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

8 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 2007 7

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

10 A more general solution © Janice Regan, CMPT 300, May 2007 9 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) }

11 © Janice Regan, CMPT 300, May 2007 10 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

12 © Janice Regan, CMPT 300, May 2007 11 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

13 © Janice Regan, CMPT 300, May 2007 12 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 }

14 © Janice Regan, CMPT 300, May 2007 13 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] ); }

15 © Janice Regan, CMPT 300, May 2007 14 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 ); }

16 © Janice Regan, CMPT 300, May 2007 15 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] ) }

17 © Janice Regan, CMPT 300, May 2007 16 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)

18 © Janice Regan, CMPT 300, May 2007 17 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

19 © Janice Regan, CMPT 300, May 2007 18 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

20 © Janice Regan, CMPT 300, May 2007 19 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

21 © Janice Regan, CMPT 300, May 2007 20 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

22 © Janice Regan, CMPT 300, May 2007 21 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

23 © Janice Regan, CMPT 300, May 2007 22 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

24 © Janice Regan, CMPT 300, May 2007 23 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

25 © Janice Regan, CMPT 300, May 2007 24 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

26 © Janice Regan, CMPT 300, May 2007 25 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

27 © Janice Regan, CMPT 300, May 2007 26 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 }

28 © Janice Regan, CMPT 300, May 2007 27 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(); }

29 © Janice Regan, CMPT 300, May 2007 28 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

30 © Janice Regan, CMPT 300, May 2007 29 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

31 © Janice Regan, CMPT 300, May 2007 30 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

32 © Janice Regan, CMPT 300, May 2007 31 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)

33 © Janice Regan, CMPT 300, May 2007 32 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); }

34 © Janice Regan, CMPT 300, May 2007 33 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

35 © Janice Regan, CMPT 300, May 2007 34 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); }


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

Similar presentations


Ads by Google