Synchronization MethodsSynchronization Methods

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

CS 105“Tour of the Black Holes of Computing”

– 2 – CS 105

Mutual ExclusionMutual Exclusion

Need 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

Additional RequirementsAdditional Requirements

Synchronization is tricky to get rightSynchronization is tricky to get right Failure to protect critical sections Incorrect use of primitives Deadlock

Programmer-friendliness is big plusProgrammer-friendliness is big plus

– 4 – CS 105

Hardware Mutex SupportHardware Mutex Support

Test 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, if match then store second

register into word Again, indivisible Generalization of Test & Set

– 5 – CS 105

Example of Test and SetExample 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

– 6 – CS 105

Evaluating Test and SetEvaluating 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.

– 7 – CS 105

SemaphoresSemaphores

Higher-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

Test & Set)

– 8 – CS 105

MonitorsMonitors

High-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

Problems in SynchronizationProblems in Synchronization

Many 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

– 10 – CS 105

The Producer/Consumer ProblemThe 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 for one-

element buffer Perfect application for monitors

– 11 – CS 105

Producer/Consumer with MonitorsProducer/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;

– 12 – CS 105

Producer/Consumer with Monitors (continued)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;;

– 13 – CS 105

The Readers/Writers ProblemThe Readers/Writers Problem

More 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 ATMs displaying or updating bank balance

– 14 – CS 105

Readers/Writers with Semaphores (Polling Version)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);wait_a_while();wait_a_while();P(mutex);P(mutex);

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

}}}}

– 15 – CS 105

Readers/Writers with Semaphores (Polling continued)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);wait_a_while();wait_a_while();P(mutex);P(mutex);

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

}}}}

– 16 – CS 105

Readers/Writers with Semaphores (Polling continued)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?

– 17 – CS 105

Readers/Writers with MonitorsReaders/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;

– 18 – CS 105

Readers/Writers with Monitors (continued)Readers/Writers with Monitors (continued)

procedure procedure beginwriting beginwriting beginbeginif if readers readers ¬= 0¬= 0 or or someonewritingsomeonewriting

then 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;beginbegin

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

endend; ;

– 19 – CS 105

Readers/Writers with MonitorsReaders/Writers with Monitors

Characteristics 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

– 20 – CS 105

Dining PhilosophersDining Philosophers

Models 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 everyone can eat

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

Solvable with semaphores or monitors

– 21 – CS 105

Deadlock and StarvationDeadlock and Starvation

Three bad things can happen in concurrencyThree bad things can happen in concurrency

Inconsistency:Inconsistency: incorrect results, e.g. from races incorrect results, e.g. from races

Deadlock:Deadlock: Nobody can make progress Nobody can make progress

Starvation:Starvation: No deadlock, but somebody doesn’t make No deadlock, but somebody doesn’t make progressprogress

– 22 – CS 105

Drinking PhilosophersDrinking Philosophers

Extension 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 necessary 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

Solution uses Dining Philosophers as sub-problem.Solution uses Dining Philosophers as sub-problem.