Synchronization Methods

TopicsTopics Mutual-exclusion methods Producer/consumer problem Readers/writers problem

semaphores.ppt

CS 105“Tour of the Black Holes of Computing”

– 2 – CS 105

Mutual ExclusionNeed ways to enforce critical sectionsNeed ways to enforce critical sections

Prevent race conditions that cause errors

Requirements for mutual exclusionRequirements for mutual exclusion Safety: only one process/thread at a time inside CS Progress: if nobody has access and somebody wants in,

somebody gets in No starvation: if you want in, you will eventually get in

Desirable properties:Desirable properties: Efficiency: can get into CS in relatively few instructions Low load: waiting for CS doesn’t waste resources Fairness: if you want in, nobody else gets in ahead of you

twice

– 3 – CS 105

Hardware Mutex SupportTest and SetTest and Set

Read word, set it nonzero, and set condition codes All in one indivisible operation

Compare and SwapCompare and Swap Read word, compare to register, store other register into

word Again, indivisible Generalization of Test & Set

– 4 – CS 105

Example of Test and Setenter_critical_region:enter_critical_region:

lealleal lock, %eaxlock, %eax.L1:.L1: tsltsl (%eax)(%eax) ; Set lock NZ, set CC; Set lock NZ, set CC

jnejne .L1.L1 ; Loop if was already ; Loop if was already NZNZ

; We now have exclusive access; We now have exclusive accessretret

leave:critical_region:leave:critical_region:xorxor %eax, %eax%eax, %eaxmovlmovl %eax, lock%eax, lockretret

– 5 – CS 105

Evaluating Test and Set+ Very fast entry to unlocked regionVery fast entry to unlocked region+ Easy to implementEasy to implement+ Guarantees safety & progressGuarantees safety & progress- Wastes CPU when waiting (spin lock/busy wait)Wastes CPU when waiting (spin lock/busy wait)- Doesn’t make it easy for other threads to runDoesn’t make it easy for other threads to run- Extremely high memory (i.e., bus) trafficExtremely high memory (i.e., bus) traffic- Prone to errors (e.g., forget to unlock)Prone to errors (e.g., forget to unlock)- Prone to starvationProne to starvation

For these reasons, test & set is used only to implement For these reasons, test & set is used only to implement higher-level constructs.higher-level constructs.

– 6 – CS 105

SemaphoresHigher-level construct, discussed previouslyHigher-level construct, discussed previously

Invented by Edsger Dijkstra P(sem) or wait(sem) decrements and possibly waits V(sem) or signal(sem) increments and lets somebody else in

Usually implemented by operating systemUsually implemented by operating system Allows scheduler to run different thread while waiting OS can guarantee fairness and no starvation

Or can even enforce priority scheme More flexibility for user (e.g., can count things)

Still error-proneStill error-prone P’s and V’s must be matched Single extra V blows mutual exclusion entirely (compare

TSL)

– 7 – CS 105

Problems in SynchronizationMany standard problems in concurrent programmingMany standard problems in concurrent programming

Producer/consumer Readers/writers Dining philosophers Drinking philosophers Etc.

Standard problems capture common situationsStandard problems capture common situations

Also give way to evaluate proposed synchronization Also give way to evaluate proposed synchronization mechanismsmechanisms

– 8 – CS 105

MonitorsHigh-level mutual-exclusion constructHigh-level mutual-exclusion construct

Invented by C.A.R. “Tony” Hoare Difficult or impossible to use incorrectly Like Java/C++ class: combines data with functions needed

to manage it

Keys to monitor correctnessKeys to monitor correctness Data is available only to functions within monitor Specific functions (gatekeepers) control access Only one process/thread allowed inside monitor at a time Queues keep track of who is waiting for monitor

Turns out to be hard to do certain things with monitorsTurns out to be hard to do certain things with monitors Programmers wind up standing on heads or implementing

things like semaphores

– 9 – CS 105

The Producer/Consumer ProblemTwo processes communicateTwo processes communicate

Producer generates things (e.g., messages) into a buffer Consumer takes those things and uses them

Correctness requirementsCorrectness requirements Producer must wait if buffer is full Consumer must not extract things from empty buffer

SolutionsSolutions Can be done with just load/store (but tricky) We have seen simple semaphore-based solution Perfect application for monitors

– 10 – CS 105

Producer/Consumer with Semaphores

semaphore mutex = 1, full = 0, empty = N;semaphore mutex = 1, full = 0, empty = N;void producer()void producer(){{

while(1) {while(1) {message nextItem = produceItem();message nextItem = produceItem();P(&empty);P(&empty);P(&mutex);P(&mutex);enterInBuffer(nextItem);enterInBuffer(nextItem);V(&mutex);V(&mutex);V(&full);V(&full);

}}}}

– 11 – CS 105

Producer/Consumer with Semaphores (continued)

void consumer()void consumer(){{

while(1) {while(1) {P(&full);P(&full);P(&mutex);P(&mutex);message nextItem = message nextItem =

removeFromBuffer();removeFromBuffer();V(&mutex);V(&mutex);V(&empty);V(&empty);consumeItem(nextItem);consumeItem(nextItem);

}}}}

– 12 – CS 105

Producer/Consumer with Monitors

monitormonitor producerconsumermonitor; producerconsumermonitor;var var buffer[0..slots-1] buffer[0..slots-1] ofof message; message;

slotsinuse: 0..slots;slotsinuse: 0..slots;nexttofill, nexttoempty: 0..slots-1;nexttofill, nexttoempty: 0..slots-1;bufferhasdata, bufferhasspace: condition;bufferhasdata, bufferhasspace: condition;

procedureprocedure fillslot( fillslot(var var data: message) data: message) beginbeginif if slotsinuse := slots;slotsinuse := slots;then then wait(bufferhasspace);wait(bufferhasspace);buffer[nexttofill] := data;buffer[nexttofill] := data;nexttofill := (nexttofill + 1) nexttofill := (nexttofill + 1) modmod slots; slots;

slotsinuse := slotsinuse + 1;slotsinuse := slotsinuse + 1;signal(bufferhasdata);signal(bufferhasdata);

end;end;

– 13 – CS 105

Producer/Consumer with Monitors (continued)

procedureprocedure emptyslot( emptyslot(varvar data: message) data: message) beginbeginif if slotsinuse = 0;slotsinuse = 0;then then wait(bufferhasdata);wait(bufferhasdata);data := buffer[nexttoempty];data := buffer[nexttoempty];nexttoempty = (nexttoempty + 1) nexttoempty = (nexttoempty + 1) modmod slots; slots;

slotsinuse := slotsinuse – 1;slotsinuse := slotsinuse – 1;signal(bufferhasspace);signal(bufferhasspace);

end;end;beginbegin

slotsinuse := 0;slotsinuse := 0;nexttofill := 0;nexttofill := 0;nexttoempty := 0;nexttoempty := 0;

endend;;

– 14 – CS 105

The Readers/Writers ProblemMore complex than producer/consumerMore complex than producer/consumer

Many processes accessing single resource Some read, some write (some could do both) OK for many to read at once

No danger of stepping on each others’ feet Only one writer allowed at a time

Examples:Examples: Shared access to file Multiple producers, multiple consumers

– 15 – CS 105

Readers/Writers with Semaphores (Polling Version)semaphore mutex = 1;semaphore mutex = 1;int nreaders = 0, nwriters = 0;int nreaders = 0, nwriters = 0;void reader()void reader(){{

while (1) {while (1) {P(mutex);P(mutex);while (nwriters != 0) {while (nwriters != 0) {V(mutex);V(mutex);pause();pause();P(mutex);P(mutex);}}nreaders++;nreaders++;V(mutex);V(mutex);read();read();P(mutex);P(mutex);nreaders--;nreaders--;V(mutex);V(mutex);}}

}}

– 16 – CS 105

Readers/Writers with Semaphores (Polling continued)void writer()void writer(){{

while (1) {while (1) {P(mutex);P(mutex);while (nreaders + nwriters != 0) {while (nreaders + nwriters != 0) {

V(mutex);V(mutex);pause();pause();P(mutex);P(mutex);

}}nwriters++;nwriters++;V(mutex);V(mutex);read();read();P(mutex);P(mutex);nwriters--;nwriters--;V(mutex);V(mutex);

}}}}

– 17 – CS 105

Readers/Writers with Semaphores (Polling continued)What are the drawbacks of this approach?What are the drawbacks of this approach?

How can we write a non-polling version?How can we write a non-polling version?

– 18 – CS 105

Readers/Writers with Monitorsmonitor monitor readersandwriters;readersandwriters;varvar readers: integer; readers: integer;

someonewriting: boolean;someonewriting: boolean;readallowed, writeallowed: condition;readallowed, writeallowed: condition;

procedure procedure beginreading beginreading beginbeginif if someonewriting someonewriting or or queue(writeallowed)queue(writeallowed)

then then wait(readallowed);wait(readallowed);readers := readers + 1;readers := readers + 1;signal(readallowed);signal(readallowed);end;end;

procedure procedure donereading donereading beginbeginreaders := readers – 1;readers := readers – 1;ifif readers = 0 readers = 0 then then signal(writeallowed);signal(writeallowed);end;end;

– 19 – CS 105

Readers/Writers with Monitors (continued)

procedure procedure beginwriting beginwriting beginbeginif if readers readers ¬= 0¬= 0 or or someonewritingsomeonewritingthen then wait(writeallowed);wait(writeallowed);someonewriting := true;someonewriting := true;end;end;

procedure procedure donewriting donewriting beginbeginsomeonewriting := false;someonewriting := false;ifif queue(readallowed) queue(readallowed)then then signal(readallowed);signal(readallowed);elseelse signal(writeallowed); signal(writeallowed);end;end;

beginbeginreaders := 0;readers := 0;someonewriting := false;someonewriting := false;

endend; ;

– 20 – CS 105

Readers/Writers with MonitorsCharacteristics of solutionCharacteristics of solution

No starvation Arriving readers wait if writer is waiting Group of readers runs after each writer Arrival order of writer, writer, reader runs in different order Requires several auxiliary variables

– 21 – CS 105

DeadlockConsider following program:Consider following program:semaphore a = 1, b = 1;semaphore a = 1, b = 1;void func1()void func1(){{

P(a);P(a);P(b);P(b);do_something();do_something();V(a);V(a);V(b);V(b);

}}void func2()void func2(){{

P(b);P(b);P(a);P(a);do_something_else();do_something_else();V(b);V(b);V(a);V(a);

}}

– 22 – CS 105

Dining PhilosophersModels many important synchronization problemsModels many important synchronization problems

Most famous concurrency problemMost famous concurrency problem

Posed by DijkstraPosed by Dijkstra

CharacteristicsCharacteristics Five philosophers alternate thinking and eating Only food is spaghetti

Requires two forks Each philosopher has assigned seat at round table One fork between each pair of plates Problem: control access to forks, such that every can eat

Note that “pick up left, then pick up right” doesn’t work Solvable with semaphores

– 23 – CS 105

Drinking PhilosophersExtension of dining philosophersExtension of dining philosophers

Arbitrary number of philosophersArbitrary number of philosophers

Each likes own drink, mixed from bottles on tableEach likes own drink, mixed from bottles on table Can only mix drink when holding all bottles Each drink uses different subset of bottles

Problem: control access to bottles, such that there is Problem: control access to bottles, such that there is no deadlock and no starvationno deadlock and no starvation