1 Reader/Writer Lock: Second Try Reader/Writer Lock: Second Try - PDF document

SharedLock SharedLock : Reader/Writer Lock : Reader/Writer Lock A reader/write lock or SharedLock is a new kind of “lock” that is similar to our old definition: • supports Acquire and Release primitives Synchronization: Going Deeper Synchronization: Going Deeper • guarantees mutual exclusion when a writer is present But : a SharedLock provides better concurrency for readers when no writer is present. often used in database systems class SharedLock { AcquireRead(); /* shared mode */ easy to implement using mutexes AcquireWrite(); /* exclusive mode */ and condition variables ReleaseRead(); a classic synchronization problem ReleaseWrite(); } Reader/Writer Lock Illustrated Reader/Writer Lock Illustrated Reader/Writer Lock: First Cut Reader/Writer Lock: First Cut int i; /* # active readers, or -1 if writer */ If each thread acquires the Lock rwMx ; SharedLock:: ReleaseWrite () { Condition rwCv ; lock in exclusive (*write) rwMx.Acquire(); Multiple readers may hold mode, SharedLock functions the lock concurrently in SharedLock:: AcquireWrite () { i = 0; A r exactly as an ordinary mutex. A r shared mode. A w rwMx.Acquire(); rwCv.Broadcast(); while (i != 0) rwMx.Release(); R r R r rwCv.Wait(&rwMx); } i = -1; Writers always hold the lock in exclusive mode, rwMx.Release(); R w and must wait for all SharedLock:: ReleaseRead () { } readers or writer to exit. rwMx.Acquire(); SharedLock:: AcquireRead () { i -= 1; rwMx.Acquire(); mode read write max allowed if (i == 0) while (i < 0) shared yes no many rwCv.Signal(); rwCv.Wait(&rwMx); exclusive yes yes one rwMx.Release(); i += 1; not holder no no many } rwMx.Release(); } The Little The Little Mutex MutexInside Inside SharedLock SharedLock Limitations of the SharedLock Limitations of the SharedLockImplementation Implementation This implementation has weaknesses discussed in [Birrell89]. • spurious lock conflicts (on a multiprocessor): multiple waiters contend for the mutex after a signal or broadcast. A r A r Solution : drop themutex before signaling. A w (If the signal primitive permits it.) R r R r • spurious wakeups A r ReleaseWrite awakens writers as well as readers. Solution : add a separate condition variable for writers. R w • starvation R r How can we be sure that a waiting writer will ever pass its acquire if faced with a continuous stream of arriving readers? 1

Reader/Writer Lock: Second Try Reader/Writer Lock: Second Try Guidelines for Condition Variables Guidelines for Condition Variables 1. Understand/document the condition(s) associated with each CV. SharedLock:: AcquireWrite () { SharedLock:: ReleaseWrite () { What are the waiters waiting for? rwMx.Acquire(); rwMx.Acquire(); i = 0; while (i != 0) When can a waiter expect a signal ? if (readersWaiting) wCv.Wait(&rwMx); rCv.Broadcast(); 2. Always check the condition to detect spurious wakeups after returning i = -1; else rwMx.Release(); from a wait : “loop before you leap”! wcv .Signal(); } Another thread may beat you to the mutex. rwMx.Release(); } SharedLock:: AcquireRead () { The signaler may be careless. SharedLock:: ReleaseRead () { rwMx.Acquire(); A single condition variable may have multiple conditions. rwMx.Acquire(); while (i < 0) i -= 1; ...rCv.Wait(&rwMx);... 3. Don’t forget: signals on condition variables do not stack! if (i == 0) i += 1; A signal will be lost if nobody is waiting: always check the wait rwMx.Release(); wCv.Signal(); rwMx.Release(); condition before calling wait . } } Starvation Starvation Deadlock Deadlock The reader/writer lock example illustrates starvation : under load, a writer Deadlock is closely related to starvation. will be stalled forever by a stream of readers. • Processes wait forever for each other to wake up and/or • Example : a one-lane bridge or tunnel . release resources. Wait for oncoming car to exit the bridge before entering. • Example: traffic gridlock . Repeat as necessary. The difference between deadlock and starvation is subtle. • Problem : a “writer” may never be able to cross if faced with • With starvation, there always exists a schedule that feeds the a continuous stream of oncoming “readers”. starving party. • Solution : some reader must politely stop before entering, The situation may resolve itself…if you’re lucky. even though it is not forced to wait by oncoming traffic. • Once deadlock occurs, it cannot be resolved by any possible Use extra synchronization to control the lock scheduling policy. future schedule. Complicates the implementation: optimize only if necessary. …though there may exist schedules that avoid deadlock. Dining Philosophers Dining Philosophers Four Preconditions for Deadlock Four Preconditions for Deadlock • N processes share N resources Four conditions must be present for deadlock to occur: • resource requests occur in pairs A 4 1. Non-preemptability . Resource ownership (e.g., by threads) 1 • random think times is non-preemptable . D B • hungry philosopher grabs a fork Resources are never taken away from the holder. • ...and doesn’t let go 3 C 2 2. Exclusion . Some thread cannot acquire a resource that is • ...until the other fork is free held by another thread. • ...and the linguine is eaten while(true) { 3. Hold-and-wait . Holder blocks awaiting another resource. Think(); AcquireForks(); Eat(); 4. Circular waiting . Threads acquire resources out of order. ReleaseForks(); } 2

Resource Graphs Resource Graphs Not All Schedules Lead to Collisions Not All Schedules Lead to Collisions Given the four preconditions, some schedules may lead to circular waits . The scheduler chooses a path of the executions of the threads/processes competing for resources. • Deadlock is easily seen with a resource graph or wait-for graph. Synchronization constrains the schedule to avoid illegal states. The graph hasa vertex for each process and each resource . Some paths “just happen” to dodge dangerous states as well. If process A holds resource R , add an arc from R to A . If process A is waiting for resource R , add an arc from A to R . What is the probability that philosophers will deadlock? The system is deadlocked iff the wait-for graph has at least one cycle. • How does the probability change as: think times increase? S n A A grabs fork 1 and B grabs fork 2 and number of philosophers increases? waits for fork 2 . 1 2 waits for fork 1 . assign B request RTG for Two Philosophers RTG for Two Philosophers Two Philosophers Living Dangerously Two Philosophers Living Dangerously Y 2 1 S n S m R2 R2 X R1 R1 2 1 X S n A1 A1 2 1 Y ??? S m A2 A2 (There are really only 9 states we care about: the important transitions are allocate and release events.) A1 A2 R2 R1 A1 A2 R2 R1 The Inevitable Result The Inevitable Result Dealing with Deadlock Dealing with Deadlock 1. Ignore it . “How big can those black boxes be anyway?” 2. Detect it and recover. Traverse the resource graph looking for cycles before blocking any customer. • If a cycle is found, preempt : force one party to release and restart. R2 X 3. Prevent it statically by breaking one of the preconditions. R1 • Assign a fixed partial ordering to resources; acquire in order. 2 1 • Use locks to reduce multiple resources to a single resource. A1 Y • Acquire resources in advance of need; release all to retry. 4. Avoid it dynamically by denying some resource requests. A2 no legal transitions out of this deadlock state Banker’s algorithm A1 A2 R2 R1 3