CSE 421/521 - Operating Systems Roadmap Fall 2012 • Semaphores • Classic Problems of Synchronization Lecture - IX – Bounded Buffer Problem Process Synchronization - II – Readers and Writers Problem – Dining-Philosophers Problem • Monitors • Conditional Variables • Sleeping Barber Problem Tevfik Ko ş ar University at Buffalo September 27 th , 2012 1 2 Mutual Exclusion Mutual Exclusion ! Summary of these implementations of mutual exclusion ! Problem: all implementations (2-5) rely on busy waiting ! Problem? " Impl. 1 — disabling hardware interrupts " “busy waiting” means that the process/thread continuously executes a tight loop until some condition changes # NO: race condition avoided, but can crash the system! " Impl. 2 — simple lock variable (unprotected) " busy waiting is bad: # NO: still suffers from race condition % waste of CPU time — the busy process is not doing anything useful, yet remains “Ready” instead of “Blocked” " Impl. 3 — indivisible lock variable (TSL) this will be the basis for “mutexes” % paradox of inversed priority — by looping indefinitely, a $ YES: works, but requires hardware higher-priority process B may starve a lower-priority " Impl. 4 — no-TSL toggle for two threads process A, thus preventing A from exiting CR and . . . # NO: race condition avoided inside, but lockup outside liberating B! (B is working against its own interest) " Impl. 5 — Peterson’s no-TSL, no-alternation --> we need for the waiting process to block, not keep idling! $ YES: works in software, but processing overhead 3 4 Synchronization Hardware Semaphores • Synchronization tool for critical section problem • Many systems provide hardware support for • Semaphore S – integer variable critical section code • Can only be accessed through two standard operations: • wait() and signal() • Uniprocessors – could disable interrupts • (or P() and V()) – Currently running code would execute without preemption • Classical implementation (using busy-waiting) – Generally too inefficient on multiprocessor systems • wait (S) { • Operating systems using this not broadly scalable while S <= 0 • Modern machines provide special atomic ; // no-op hardware instructions S--; } • Atomic = non-interruptable – Either test memory word and set value • signal (S) { – Or swap contents of two memory words S++; } 5 6
Semaphores as Synchronization Tool Semaphores without Busy-Waiting wait (S){ • Counting semaphore – integer value can range over an S.value--; unrestricted domain if (S.value < 0) { add this process to waiting queue; • Binary semaphore – integer value can range only block(); between 0 and 1; can be simpler to implement } – Also known as mutex locks } • Provides mutual exclusion Signal (S){ – Semaphore S; // initialized to 1 S.value++; – wait (S); if (S.value < = 0) { Critical Section remove a process P from the waiting queue; signal (S); wakeup(P); } } 7 8 Deadlock and Starvation Classical Problems of Synchronization • Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes • Bounded-Buffer Problem • Let S and Q be two semaphores initialized to 1 • Readers and Writers Problem P 0 P 1 • Dining-Philosophers Problem wait (S); wait (Q); . . wait (Q); wait (S); . . . . signal (S); signal (Q); signal (Q); signal (S); • Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended. 9 10 Bounded-Buffer Problem Bounded Buffer – 1 Semaphore Soln • The structure of the producer process int empty=N, full=0; • Shared buffer with N slots to store at most N do { items // produce an item • Producer processes data items and puts into the wait (mutex); buffer if (empty> 0){ • Consumer gets the data items from the buffer // add the item to the buffer • Variable empty keeps number of empty slots in empty --; full++; the butter } • Variable full keeps number of full items in the signal (mutex); buffer } while (true); 11 12
Bounded Buffer – 1 Semaphore Soln Bounded Buffer – 1 Semaphore Soln - II • The structure of the consumer process • The structure of the producer process int empty=N, full=0; do { do { // produce an item wait (mutex); while (empty == 0){} if (full>0){ wait (mutex); // remove an item from buffer // add the item to the buffer full--; empty++; empty --; full++; } signal (mutex); signal (mutex); } while (true); // consume the removed item } while (true); consume non-existing item! 13 14 Bounded Buffer – 1 Semaphore Soln - II Bounded Buffer – 2 Semaphore Soln • The structure of the consumer process • The structure of the producer process do { do { while (full == 0){} // produce an item wait (mutex); wait (empty); // remove an item from buffer // add the item to the buffer full--; empty++; signal (full); signal (mutex); } while (true); // consume the removed item } while (true); * Mutual Exclusion not preserved! 15 16 Bounded Buffer – 2 Semaphore Soln Bounded Buffer - 3 Semaphore Soln • The structure of the consumer process • Semaphore mutex for access to the buffer, do { initialized to 1 wait (full); • Semaphore full (number of full buffers) // remove an item from buffer initialized to 0 signal (empty); • Semaphore empty (number of empty buffers) initialized to N // consume the removed item } while (true); * Mutual Exclusion not preserved! 17 18
Bounded Buffer - 3 Semaphore Soln Bounded Buffer - 3 Semaphore Soln • The structure of the producer process • The structure of the consumer process do { do { wait (full); // produce an item wait (mutex); wait (empty); // remove an item from buffer wait (mutex); signal (mutex); // add the item to the buffer signal (empty); signal (mutex); // consume the removed item signal (full); } while (true); } while (true); 19 20 Readers-Writers Problem Readers-Writers Problem • Multiple Readers and writers concurrently accessing • The structure of a writer process the same database. do { • Multiple Readers accessing at the same time --> OK wait (wrt) ; • When there is a Writer accessing, there should be no // writing is performed other processes accessing at the same time. signal (wrt) ; } while (true) 21 22 Readers-Writers Problem (Cont.) Dining Philosophers Problem • The structure of a reader process • Five philosophers spend their time eating and thinking. do { • They are sitting in front of a round table with wait (mutex) ; spaghetti served. readercount ++ ; •There are five plates at the table and five if (readercount == 1) wait (wrt) ; chopsticks set between the plates. signal (mutex) • Eating the spaghetti requires the use of two chopsticks which the philosophers pick up one // reading is performed at a time. •Philosophers do not talk to each other. wait (mutex) ; readercount - - ; •Semaphore chopstick [5] initialized to 1 if readercount == 0) signal (wrt) ; signal (mutex) ; } while (true) 23 24
Dining-Philosophers Problem (Cont.) To Prevent Deadlock • The structure of Philosopher i : • Ensures mutual exclusion, but does not prevent deadlock Do { wait ( chopstick[i] ); • Allow philosopher to pick up her chopsticks only if both wait ( chopStick[ (i + 1) % 5] ); chopsticks are available (i.e. in critical section) • Use an asymmetric solution: an odd philosopher picks // eat up first her left chopstick and then her right chopstick; signal ( chopstick[i] ); and vice versa signal (chopstick[ (i + 1) % 5] ); // think • Exercise: Write the algorithms for the above solutions } while (true) ; 25 26 Problems with Semaphores Semaphores • Wrong use of semaphore operations: • inadequate in dealing with deadlocks – semaphores A and B , initialized to 1 • do not protect the programmer from the easy mistakes P 0 P 1 of taking a semaphore that is already held by the same wait (A); wait(B) wait (B); wait(A) process, and forgetting to release a semaphore that has & Deadlock been taken – signal (mutex) …. wait (mutex) • mostly used in low level code, eg. operating systems & violation of mutual exclusion • the trend in programming language development, though, is towards more structured forms of – wait (mutex) … wait (mutex) & Deadlock synchronization, such as monitors – Omitting of wait (mutex) or signal (mutex) (or both) & violation of mutual exclusion or deadlock 27 28 Monitors Monitor - Example • A high-level abstraction that provides a convenient and effective mechanism for process synchronization As a simple example, consider a monitor for performing transactions on a bank account. • Only one process may be active within the monitor at a time monitor account { monitor monitor-name int balance := 0 { // shared variable declarations function withdraw( int amount) { procedure P1 (…) { …. } … if amount < 0 then error "Amount may not be negative" procedure Pn (…) {……} else if balance < amount then error "Insufficient funds" else balance := balance - amount Initialization code ( ….) { … } } … } function deposit( int amount) { } if amount < 0 then error "Amount may not be negative" else balance := balance + amount • A monitor procedure takes the lock before doing anything else, and } holds it until it either finishes or waits for a condition } 29 30
Recommend
More recommend