attempt to acquire the lock. Should another writer show up before the readers get the lock, that
writer will get priority.
"But," you may ask, "won't writer priority lead to starvation of readers in some cases?" Yup. And
you can make a case for nonpreferential RWlocks, or even reader-priority. However, we are
concerned primarily with producing practical, well-performing programs, not proving theorems
about degenerate cases. RWlocks are used primarily in situations where there are a great many
read requests and very few write requests. If you have a large number of write requests, you
shouldn't be using RWlocks.
In Figure 7-1, five threads all need an RWlock. They have different priorities, which determine the
order in which they go onto the writers' sleep queue. The threads have requested the lock in the
order T1, T2, T3, T4, T5. T1 and T2 own the lock, and T5 will be awakened as soon as they both
release it, even though T3 and T4 requested the lock before T5. In Figure 7-2 we see exactly this
happening. Note the overlapping read sections for T1 and T2.
Figure 7-1. How Readers/Writer Locks Work
Figure 7-2. Execution Graph for Readers/Writer Locks
Search WWH :
