Synchronization Methods

1. Synchronization Methods CS 105“Tour of the Black Holes of Computing” • Topics • Mutual-exclusion methods • Producer/consumer problem • Readers/writers problem semaphores.ppt

2. Mutual Exclusion • Need ways to enforce critical sections • Prevent race conditions that cause errors • Requirements 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: • 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. Hardware Mutex Support • Test and Set • Read word, set it nonzero, and set condition codes • All in one indivisible operation • Compare and Swap • Read word, compare to register, store other register into word • Again, indivisible • Generalization of Test & Set

4. Example of Test and Set • enter_critical_region: • leal lock, %eax • .L1: tsl (%eax) ; Set lock NZ, set CC • jne .L1 ; Loop if was already NZ • ; We now have exclusive access • ret • leave:critical_region: • xor %eax, %eax • movl %eax, lock • ret

5. Evaluating Test and Set • Very fast entry to unlocked region • Easy to implement • Guarantees safety & progress • Wastes CPU when waiting (spin lock/busy wait) • Doesn’t make it easy for other threads to run • Extremely high memory (i.e., bus) traffic • Prone to errors (e.g., forget to unlock) • Prone to starvation For these reasons, test & set is used only to implement higher-level constructs.

6. Semaphores • Higher-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 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-prone • P’s and V’s must be matched • Single extra V blows mutual exclusion entirely (compare TSL)

7. Problems in Synchronization • Many standard problems in concurrent programming • Producer/consumer • Readers/writers • Dining philosophers • Drinking philosophers • Etc. • Standard problems capture common situations • Also give way to evaluate proposed synchronization mechanisms

8. Monitors • High-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 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 monitors • Programmers wind up standing on heads or implementing things like semaphores

9. The Producer/Consumer Problem • Two processes communicate • Producer generates things (e.g., messages) into a buffer • Consumer takes those things and uses them • Correctness requirements • Producer must wait if buffer is full • Consumer must not extract things from empty buffer • Solutions • Can be done with just load/store (but tricky) • We have seen simple semaphore-based solution • Perfect application for monitors

10. Producer/Consumer with Semaphores • semaphore mutex = 1, full = 0, empty = N; • void producer() • { • while(1) { • message nextItem = produceItem(); • P(&empty); • P(&mutex); • enterInBuffer(nextItem); • V(&mutex); • V(&full); • } • }

11. Producer/Consumer with Semaphores (continued) • void consumer() • { • while(1) { • P(&full); • P(&mutex); • message nextItem = removeFromBuffer(); • V(&mutex); • V(&empty); • consumeItem(nextItem); • } • }

12. Producer/Consumer with Monitors • monitor producerconsumermonitor; • var buffer[0..slots-1] of message; • slotsinuse: 0..slots; • nexttofill, nexttoempty: 0..slots-1; • bufferhasdata, bufferhasspace: condition; • procedure fillslot(var data: message) begin • if slotsinuse := slots; • then wait(bufferhasspace); • buffer[nexttofill] := data; • nexttofill := (nexttofill + 1) mod slots; • slotsinuse := slotsinuse + 1; • signal(bufferhasdata); • end;

13. Producer/Consumer with Monitors (continued) • procedure emptyslot(var data: message) begin • if slotsinuse = 0; • then wait(bufferhasdata); • data := buffer[nexttoempty]; • nexttoempty = (nexttoempty + 1) mod slots; • slotsinuse := slotsinuse – 1; • signal(bufferhasspace); • end; • begin • slotsinuse := 0; • nexttofill := 0; • nexttoempty := 0; • end;

14. The Readers/Writers Problem • More 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: • Shared access to file • Multiple producers, multiple consumers

15. Readers/Writers with Semaphores (Polling Version) • semaphore mutex = 1; • int nreaders = 0, nwriters = 0; • void reader() • { • while (1) { • P(mutex); • while (nwriters != 0) { • V(mutex); • pause(); • P(mutex); • } • nreaders++; • V(mutex); • read(); • P(mutex); • nreaders--; • V(mutex); • } • }

16. Readers/Writers with Semaphores (Polling continued) • void writer() • { • while (1) { • P(mutex); • while (nreaders + nwriters != 0) { • V(mutex); • pause(); • P(mutex); • } • nwriters++; • V(mutex); • read(); • P(mutex); • nwriters--; • V(mutex); • } • }

17. Readers/Writers with Semaphores (Polling continued) • What are the drawbacks of this approach? • How can we write a non-polling version?

18. Readers/Writers with Monitors • monitor readersandwriters; • var readers: integer; • someonewriting: boolean; • readallowed, writeallowed: condition; • procedure beginreading begin • if someonewriting or queue(writeallowed) • then wait(readallowed); • readers := readers + 1; • signal(readallowed); • end; • procedure donereading begin • readers := readers – 1; • if readers = 0 then signal(writeallowed); • end;

19. Readers/Writers with Monitors (continued) • procedure beginwriting begin • if readers ¬= 0or someonewriting • then wait(writeallowed); • someonewriting := true; • end; • procedure donewriting begin • someonewriting := false; • if queue(readallowed) • then signal(readallowed); • else signal(writeallowed); • end; • begin • readers := 0; • someonewriting := false; • end;

20. Readers/Writers with Monitors • Characteristics 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. Deadlock • Consider following program: • semaphore a = 1, b = 1; • void func1() • { • P(a); • P(b); • do_something(); • V(a); • V(b); • } • void func2() • { • P(b); • P(a); • do_something_else(); • V(b); • V(a); • }

22. Dining Philosophers • Models many important synchronization problems • Most famous concurrency problem • Posed by Dijkstra • Characteristics • 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. Drinking Philosophers • Extension of dining philosophers • Arbitrary number of philosophers • Each 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 no deadlock and no starvation