CS 105 Tour of the Black Holes of
CS 105 “Tour of the Black Holes of Computing” Synchronization Methods Topics n n n Mutual-exclusion methods Producer/consumer problem Readers/writers problem
Mutual Exclusion Need ways to enforce critical sections n Prevent race conditions that cause errors Requirements for mutual exclusion n 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: n n n – 2– 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 CS 105
Additional Requirements Synchronization is tricky to get right n Failure to protect critical sections n Incorrect use of primitives Deadlock n Programmer-friendliness is big plus – 3– CS 105
Hardware Mutex Support Test and Set n Read word, set it nonzero, and set condition codes n All in one indivisible operation Compare and Swap n n n – 4– Read word, compare to register, if match then store second register into word Again, indivisible Generalization of Test & Set CS 105
Example of Test and Set enter_critical_region: leal lock, %eax. L 1: tsl (%eax) ; Set lock NZ, set CC jne. L 1 ; Loop if was already NZ ; We now have exclusive access ret leave_critical_region: xor %eax, %eax movl %eax, lock ret – 5– CS 105
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– CS 105
Semaphores Higher-level construct, discussed previously n Invented by Edsger Dijkstra n P(sem) or wait(sem) decrements and possibly waits V(sem) or signal(sem) increments and lets somebody else in n Usually implemented by operating system n n Allows scheduler to run different thread while waiting OS can guarantee fairness and no starvation l Or can even enforce priority scheme n More flexibility for user (e. g. , can count things) Still error-prone n n – 7– P’s and V’s must be matched Single extra V blows mutual exclusion entirely (compare Test & Set) CS 105
Monitors High-level mutual-exclusion construct n Invented by C. A. R. “Tony” Hoare n Difficult or impossible to use incorrectly Like Java/C++ class: combines data with functions needed to manage it n Keys to monitor correctness n n 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 n – 8– Programmers wind up standing on heads or implementing things like semaphores CS 105
Problems in Synchronization Many standard problems in concurrent programming n Producer/consumer n Readers/writers Dining philosophers Drinking philosophers Etc. n n n Standard problems capture common situations Also give way to evaluate proposed synchronization mechanisms – 9– CS 105
The Producer/Consumer Problem Two processes communicate n Producer generates things (e. g. , messages) into a buffer n Consumer takes those things and uses them Correctness requirements n n Producer must wait if buffer is full Consumer must not extract things from empty buffer Solutions n n n – 10 – Can be done with just load/store (but tricky) We have seen simple semaphore-based solution for oneelement buffer Perfect application for monitors CS 105
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; – 11 – CS 105
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; – 12 – CS 105
The Readers/Writers Problem More complex than producer/consumer n Many processes accessingle resource n Some read, some write (some could do both) OK for many to read at once n l No danger of stepping on each others’ feet n Only one writer allowed at a time Examples: n n – 13 – Shared access to file ATMs displaying or updating bank balance CS 105
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); wait_a_while(); P(mutex); } nreaders++; V(mutex); read(); P(mutex); nreaders--; V(mutex); } } – 14 – CS 105
Readers/Writers with Semaphores (Polling continued) void writer() { while (1) { P(mutex); while (nreaders + nwriters != 0) { V(mutex); wait_a_while(); P(mutex); } nwriters++; V(mutex); write(); P(mutex); nwriters--; V(mutex); } } – 15 – CS 105
Readers/Writers with Semaphores (Polling continued) What are the drawbacks of this approach? How can we write a non-polling version? – 16 – CS 105
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; – 17 – CS 105
Readers/Writers with Monitors (continued) procedure beginwriting begin if readers ¬= 0 or 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; – 18 – CS 105
Readers/Writers with Monitors Characteristics of solution n No starvation n Arriving readers wait if writer is waiting Group of readers runs after each writer Arrival order of writer, reader runs in different order Requires several auxiliary variables n n n – 19 – CS 105
Dining Philosophers Models many important synchronization problems Most famous concurrency problem Posed by Dijkstra Characteristics n n Five philosophers alternate thinking and eating Only food is spaghetti l Requires two forks n n n 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 l Note that “pick up left, then pick up right” doesn’t work n – 20 – Solvable with semaphores or monitors CS 105
Deadlock and Starvation Three bad things can happen in concurrency Inconsistency: incorrect results, e. g. from races Deadlock: Nobody can make progress Starvation: No deadlock, but somebody doesn’t make progress – 21 – CS 105
Drinking Philosophers Extension of dining philosophers Arbitrary number of philosophers Each likes own drink, mixed from bottles on table n n 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 no deadlock and no starvation – 22 – CS 105
- Slides: 22