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 Problem shared 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 threadReason(s) to wait?How to implement?

Consumer threadReason(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 variablesin = 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)

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

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

}

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 Monitormonitor 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 variablesreadercount = 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 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);

}

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 exclusionwait(cSem); // blockwait(mutex); // regain exclusion before

accessing // shared variables What about a signal on a condition variable?

Dining Philosophersmonitor 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 Philosophersvoid pickup(int i) {

state[i] = hungry;test(i); // check if OK to eatif (state[i] != eating)

self[i].wait();}

void putdown(int i) {state[i] = thinking;// test left and right neighborstest((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