1. CS444/CS544 Operating Systems Classic Synchronization Problems 3/5/2007 Prof. Searleman jets@clarkson.edu

2. Outline Setting up a Synchronization solution Classic Synchronization Problems Readers/Writers Summary: Synchronization Primitives Implementing Synchronization Primitives NOTE: Read: Chapter 7 Makeup class to be scheduled Friday Exam#2 – Tues. 3/13, 7:00 pm, SC160 Exam#2

3. Setting up a synchronization problem How to use semaphores How to use a monitor How to use condition variables Shown in class

4. Classical Synchronization Problems Bounded-Buffer Problem (also called Producer-Consumer) one-way communication with limited resources Dining-Philosophers Problem shared resources Readers and Writers Problem shared database

5. Readers/writers Shared data area being accessed by multiple processes/threads Reader threads look but don’t touch We can allow multiple readers at a time. Why? Writer threads touch too. If a writer present, no other writers and no readers. Why? Is Producer/Consumer a subset of this? Producers and consumers are both writers Producer = writer type A; Consumer = writer type B; and there are no readers What might be a reader? Report current num full.

6. Semaphore Solution to Readers/ Writers semaphore_t mutex; semaphore_t okToWrite; int numReaders; void init{ mutex.value = 1; okToWrite.value = 1; numReaders = 0; } void writer (){ wait(okToWrite); /* do writing 1 */ signal(okToWrite); } void reader (){ wait(mutex); numReaders++; if (numReaders == 1) wait(okToWrite); signal(mutex); /* do reading 2 */ wait(mutex); numReaders--; if (numReaders == 0) signal(okToWrite); signal (mutex); } Can we do better? Fairness to writers? (Reader Preference) ( 1 could pass in pointer to write function) ( 2 could pass in pointer to read function) Problem?

7. Monitor Solution to Readers/Writers reader thread reason(s) to wait? how to implement? writer thread reason(s) to wait? how to implement? “fairness” don’t want to starve either readers or writers

8. Reader/Writer Monitor monitor RW { // shared variables condition OKtoread, OKtowrite; int readercount, waitingWriters, waitingReaders; boolean busy; // 4 monitor procedures void startRead(); void endRead(); void startWrite(); void endWrite(); // initialization code for shared variables readercount = 0; busy = false; waitingWriters = waitingReaders = 0; } // end monitor RW

9. Reader & Writer threads: READER : repeat { RW.startRead(); /* read database */ RW.endRead(); } until done; WRITER: repeat { RW.startWrite(); /* update database */ RW.endWrite(); } until done;

10. // Monitor procedures for readers: void startRead(){ if ( busy || (waitingWriters > 0) ) { waitingReader++; OKtoRead.wait(); waitingReaders--; } readercount = readercount + 1; OKtoRead.signal(); } void endRead(){ readercount = readercount - 1; if (readercount == 0) OKtoWrite.signal(); }

11. // Monitor procedures for writers: void startWrite(){ if ( (readercount != 0) || busy ) { waitingWriters++; OKtoWrite.wait(); waitingWriters--; } busy = true; } void endWrite(){ busy = false; if (waitingReaders > 0) OKtoRead.signal(); else OKtoWrite.signal(); }

12. Semaphore Solution to Readers/ Writers (Fair) semaphore_t readCountMutex, incoming, next; int numReaders; BOOL writeInProgress,readInProgress; void init{ readCountMutex.value = 1; incoming.value = 1; next.value = 1; numReaders = 0; writeInProgress = FALSE; readInProgress = FALSE; }

13. void writer() { wait(incoming); wait(next); writeInProgress = TRUE; // let someone else move // on, and wait on next signal(incoming); // do writing writeInProgress = FALSE; if (next.value == 0){ signal(next); } void reader (){ wait(incoming); if (!readInProgress) wait(next); wait(readCountMutex); numReaders++; readInProgress = TRUE; signal(readCountMutex); // if next thread on incoming // is writer, will block on next signal(incoming); // do reading wait(readCountMutex); numReaders--; if (numReaders == 0){ readInProgress = FALSE; if (next.value == 0){ signal (next); } signal(readCountMutex); }

14. Remember Game is obtaining highest possible degree of concurrency and greatest ease of programming Tension Simple high granularity locks easy to program Simple high granularity locks often means low concurrency Getting more concurrency means Finer granularity locks, more locks More complicated rules for concurrent access