CS444/CS544 Operating Systems

CS444/CS544Operating Systems Synchronization 3/21/2006 Prof. Searleman jets@clarkson.edu

Outline • Synchronization methods • Monitors & Semaphore solutions • Producer/Consumer (bounded buffer) • Readers/Writers • Dining Philosophers NOTE: • HW#6 and Lab#2 due this week (by Friday) • HW#7 posted, due 3/28 • Read: Chapter 8 • Class on Thursday is HERE (Snell, NOT lab)

Announcements: IBM Workshopon IMS, Saturday, 9-4, ITL Want a Career in IMS?What is IMS you ask?Well if you've ever used an ATM then you've probably used IMS. If you've done Web banking, you've probably used IMS. If you've called FEDEX to track your package, guess what? FEDEX uses IMS. Major fortune 500 companies use it.IMS (Information Management System) is IBM's premiere Hierarchical Database system that runs on a mainframe system (those large corporate computers).Visit the IMS home page at http://www-306.ibm.com/software/data/ims/

Announcements: IBM Workshopon IMS, Saturday, 9-4, ITL The first half of the seminar will describe the following:- Architecture of IMS - The different IMS database types- Database recovery facilities.- IMS Transaction management.- Some of the special facilities: MSC, RSR & XRF. The second half of the seminar contains a live demo operating and using an IMS system followed by discussions of the various Job opportunities in IMS: System programming, Database Administration, Application Programming, Testing and Technical support Lunch and refreshments will be provided!!! Please see Prof. Searleman or Prof. Matthews to sign up

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

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

Bounded BufferProducer/Consumer • Finite size buffer (array) in memory shared by multiple processes/threads • Producer threads “produce” an item and place it in the buffer • Consumer threads remove an item from the buffer and “consume” it • Why do we need synchronization? • Shared data = the buffer state • Which parts of buffer are free? Which filled? • What can go wrong? • Producer doesn’t stop when no free spaces; Consumer tries to consume an empty space; Consumer tries to consume a space that is only half-filled by the producer; Two producers try to produce into same space; Two consumers try to consume the same space,…

Producer thread Reason(s) to wait? How to implement? • Consumer thread Reason(s) to wait? How to implement? • CONCEPT: Producers produce items to be stored in the buffer. Consumers remove and consume items which have been stored. Mutual exclusion must be enforced on the buffer itself. Moreover, producers can store only when there is an empty slot, and consumers can remove only when there is a full slot.

Monitor Solution to Producer/Consumer • The buffer and its control variables are encapsulated by a monitor. The monitor provides procedures to put an item in the buffer and to take an item out of the buffer. The monitor includes two condition variables: slot_free represents the condition that there is space for an item, and item_present represents the condition that at least one item is present in the buffer. • In this example, the buffer is implemented as an array of size MAX treated as a circular (ring) buffer. Variables in and out give the index of the next position for putting in and taking out (if any). Variable count gives the number of items in the buffer.

Structure of a Monitor monitor BB { // shared variables condition slot_free, item_present; anytype buffer[MAX]; int in, out, count; // monitor procedures void put_in_buffer(anytype item); anytype get_from_buffer(void); // initialization code for shared variables in = 0; out = 0; count = 0; } // end monitor BB

Producer & Consumer threads: • PRODUCER : repeat { /* produce an item */ item = produce(); /* put it in the buffer */ BB.put_in_buffer(item); } until done; • CONSUMER: repeat { /* get item from the buffer */ item = BB. get_from_buffer(); /* consume it */ consume(item); } until done;

void put_in_buffer(anytype item) { /* if no space is available, wait for one */ if (count >= MAX) slot_free.wait(); /* store the item */ buffer[in] = item; in = in + 1 mod n; count = count + 1; /* signal that the item is present */ item_present.signal(); } anytype get_from_buffer(void){ anytype item; /* if no items are present, wait for one */ if (count <= 0) item_present.wait(); /* get the next item */ item = buffer[out]; out = out + 1 mod n; count = count - 1; /* announce that a space is free */ slot_free.signal(); /* return the item */ return(item); }

Semaphore Solution to Bounded-Buffer semaphore_t mutex; semaphore_t full; semaphore_t empty; container_t { BOOL free = TRUE; item_t item; } container_t buffer[FIXED_SIZE]; void initBoundedBuffer{ mutex.value = 1; full.value = 0; empty.value = FIXED_SIZE }

Semaphore Solution to Bounded-Buffer void producer (){ container_t *which; wait(empty); wait(mutex); which = findFreeBuffer(); which->free = FALSE; which->item = produceItem(); signal(mutex); signal(full); } void consumer (){ container_t *which; wait(full); wait(mutex); which = findFullBuffer(); consumeItem(which->item); which->free = TRUE; signal(mutex); signal(empty); } • Can we do better? Lock held while produce/consume? Exercise

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.

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

Monitor Solution toReaders/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

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

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

// 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(); }

// 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(); }

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; }

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); } 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); } }

Converting a monitor solution to a semaphore solution Basic concept: • Each condition c; simulated with semaphore cSem = 0; • For mutual exclusion, introduce a new semaphore: semaphore mutex = 1; • A wait on a condition variable c: c.wait() becomes: signal(mutex); // release exclusion wait(cSem); // block wait(mutex); // regain exclusion before accessing // shared variables • What about a signal on a condition variable?

Dining Philosophers monitor DP { enum State{thinking, hungry, eating}; State moods[NUM_PHIL]; condition self[NUM_PHIL]; void pickup(int i); void putdown(int i); void test(int i); void init() { for (int i = 0; i < NUM_PHIL; i++) state[i] = thinking; } } // end DP

Dining Philosophers void pickup(int i) { state[i] = hungry; test(i); // check if OK to eat if (state[i] != eating) self[i].wait(); } void putdown(int i) { state[i] = thinking; // test left and right neighbors test((i+ (NUM_PHIL-1 )) % NUM_PHIL); test((i+1) % NUM_PHIL); }

Dining Philosophers void test(int i) { if ((state[(i + NUM_PHIL-1) % NUM_PHIL] != eating) && (state[i] == hungry) && (state[(i + 1) % NUM_PHILOSOPHERS] != eating)) { state[i] = eating; self[i].signal(); } }

Philosopher Threads void philosophersLife(int i) { while(1){ think(); DP.pickupChopticks(); eat(); DP.putdownChopsicks(); } }

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

Other Classic Synchronization Problems • Sleeping Barber • Traffic lights for two lane road through a one lane tunnel

CS444/CS544 Operating Systems