CS 372: Operating Systems Mike Dahlin 1 02/18/10 Lecture #10: Synchronization wrap up ********************************* Review -- 1 min ********************************* Monitor = lock + condition variables Mesa v. Hoare semantics Advice/Summary Fall 2001 midterm: • Every program with incorrect semantic behavior violated at least one rule • >90% of programs that violated at least one rule were “obviously” semantically incorrect (that is, I could see the bug within seconds of looking at the program; there may have been additional bugs…) o All that violate one rule are wrong – they are harder to read, understand, maintain ********************************* Outline - 1 min ********************************** Readers/Writers Monitors v. Semaphores Concurrency Summary ********************************* Preview - 1 min ********************************* Other issues – scheduling, deadlock ********************************* Lecture - 20 min *********************************CS 372: Operating Systems Mike Dahlin 2 02/18/10 1. Readers/Writers 1.1 Motivation Shared database (for example, bank balances, or airline seats) Two classes of users: Readers – never modify database Writers – read and modify data Using a single mutex lock would be overly restrictive. Instead, want: many readers at same time only one writer at same time 1.2 Constraints Notice: for every constraint, there is a synchronization variable. This time different types for different purposes. 1) Reader can access database when no writers (Condition okToRead) 2) Writers can access database when no readers or writers (condition okToWrite) 3) Only one thread manipulates shared variables at a time (mutex) 1.3 Solution Basic structure Database::read() check in -- wait until no writers access database check out – wake up waiting writer Database::write() check in -- wait until no readers or writers access database check out – wake up waiting readers or writers State variables: AR = 0; // # active readers AW = 0; // # active writers WR = 0; // # waiting readersCS 372: Operating Systems Mike Dahlin 3 02/18/10 WW = 0; // # waiting writers Condition okToRead = NIL; Condition okToWrite = NIL; Lock lock = FREE; Code: Database::read(){ startRead(); // first, check self into the system Access Data doneRead(); // Check self out of system } Database::startRead(){ lock.Acquire(); while((AW + WW) > 0){ WR++; okToRead.Wait(&lock); WR--; } AR++; lock.Release(); } Database::doneRead(){ lock.Acquire(); AR--; if(AR == 0 && WW > 0){ // if no other readers still okToWrite.Signal(); // active, wake up writer } lock.Release(); } Database::write(){ // symmetrical startWrite(); // check in accessData doneWrite(); // check out } Database::startWrite(){CS 372: Operating Systems Mike Dahlin 4 02/18/10 lock.Acquire(); while((AW + AR) > 0){ // check if safe to write // if any readers or writers, wait WW++; okToWrite->Wait(&lock); WW--; } AW++; lock.Release(); } Database::doneWrite(){ lock.Acquire(); AW--; if(WW > 0){ okToWrite->Signal(); // give priority to writers } else if (WR > 0){ okToRead->Broadcast(); } lock.Release(); } Question 1) Can readers starve? 2) Why does checkRead need a while? 3) Suppose we had a large DB with many records, and we want many users to access it at once. Probably want to allow two different people to update their bank balances at the same time, right? What are issues? 2. Example: Sleeping Barber (Midterm 2002) The shop has a barber, a barber chair, and a waiting room with NCHAIRS chairs. If there are no customers present, the barber sits in the barber chair and falls asleep. When a customer arrives, he wakes the sleeping barber. If an additional customer arrives while the barber is cutting hair, he sits in a waiting room chair if one is available. If no chairs are available, he leaves the shop. When the barber finishes cutting a customer’s hair, he tells the customer to leave; then, if there are any customers in the waiting room heCS 372: Operating Systems Mike Dahlin 5 02/18/10 announces that the next customer can sit down. Customers in the waiting room get their hair cut in FIFO order. The barber shop can be modeled as 2 shared objects, a BarberChair with the methods napInChair(), wakeBarber(), sitInChair(), cutHair(), and tellCustomerDone(). The BarberChair must have a state variable with the following states: EMPTY, BARBER_IN_CHAIR, LONG_HAIR_CUSTOMER_IN_CHAIR, SHORT_HAIR_CUSTOMER_IN_CHAIR. Note that neither a customer or barber should sit down until the previous customer is out of the chair (state == EMPTY). Note that cutHair() must not return until the customer is sitting in the chair (LONG_HAIR_CUSTOMER_IN_CHAIR). And note that a customer should not get out of the chair (e.g., return from sit in chair) until his hair is cut (SHORT_HAIR_CUSTOMER_IN_CHAIR). The barber should only get in the chair (BARBER_IN_CHAIR) if no customers are waiting. You may need additional state variables. The WaitingRoom has the methods enter() which immediately returns WR_FULL if the waiting room is full or (immediately or eventually) returns MY_TURN when it is the caller’s turn to get his hair cut, and it has the method callNextCustomer() which returns WR_BUSY or WR_EMPTY depending on if there is a customer in the waiting room or not. Customers are served in FIFO order. Thus, each customer thread executes the code: Customer(WaitingRoom *wr, BarberChair *bc) { status = wr->enter(); if(status == WR_FULL){ return; } bc->wakeBarber(); bc->sitInChair(); // Wait for chair to be EMPTY // Make state LONG_HAIR_CUSTOMER_IN_CHAIR // Wait until SHORT_HAIR_CUSTOMER_IN_CHAIR // then make chair EMPTY and return return; } The barber thread executes the code: Barber(WaitingRoom *wr, BarberChair *bc) { while(1){ // A barber’s work is never done status = wr->callNextCustomer(); if(status == WR_EMPTY){ bc->napInChair(); // Set state to BARBER_IN_CHAIR; return with state EMPTY } bc->cutHair(); // Block until LONG_HAIR_CUSTOMER_IN_CHAIR; // Return with SHORT_HAIR_CUSTOMER_IN_CHAIR bc->tellCustomerDone(); // Return when EMPTY } } Write the code for the WaitingRoom class and the BarberChair class. Use locks and condition variables for synchronization and