CS444/CS544 Operating Systems Synchronization 2/21/2007 Prof. Searleman [email protected].
CS444/CS544 Operating Systems Synchronization 3/21/2006 Prof. Searleman [email protected].
-
date post
20-Dec-2015 -
Category
Documents
-
view
224 -
download
0
Transcript of CS444/CS544 Operating Systems Synchronization 3/21/2006 Prof. Searleman [email protected].
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