Chapter 7. Complexities
·
Complex Locking Primitives
·
Timeouts
·
Other Synchronization Variables
·
Volatile
·
Performance
·
Synchronization Problems
·
APIs Used in this Chapter
·
The Class Extensions.RWLock
·
The Class Extensions.Barrier
·
The Class Extensions.SingleBarrier
In which a series of more complex synchronization variables and options are presented and the
trade-off between them and the simpler ones are discussed. Synchronization problems and
techniques for dealing with them conclude the chapter.
Complex Locking Primitives
There are times when a simple mutex does not provide enough functionality. There are situations
in which you can improve your program's efficiency or fairness by implementing more complex
locking primitives. Keep in mind that the locks described below are more complex and therefore
slower than normal mutex locks, generally by a factor of 2 or more. They are not generally useful,
so be advised to consider your requirements closely before using them.
Readers/Writer Locks
Sometimes you will find yourself with a shared data structure that gets read often but written only
seldom. The reading of that structure may require a significant amount of time (perhaps it's a long
list through which you do searches). It would seem a waste to put a mutex around it and require all
the threads to go through it one at a time when they're not changing anything. Hence,
readers/writer locks.
With an RWlock, you can have any number of threads reading the data concurrently, whereas
writers are serialized. The only drawback to RWlocks is that they are more expensive than
mutexes. So you must consider your data structure, how long you expect to be in it, how much
contention you expect, and choose between a mutex and an RWlock on those bases. As a rule of
thumb, a simple global variable will always be locked with a mutex, while searching down a
1000-element, linked list will often be locked with an RWlock.
The operation of RWlocks is as follows: The first reader that requests the lock will get it.
Subsequent readers also get the lock, and all of them are allowed to read the data concurrently.
When a writer requests the lock, it is put on a sleep queue until all the readers exit. A second
writer will also be put on the writer's sleep queue. Should a new reader show up at this point, it
will be put on the reader's sleep queue until all the writers have completed. Further writers will be
placed on the same writer's sleep queue as the others (hence, in front of the waiting reader),
meaning that writers are always favored over readers. (Writer priority is simply a choice we made
in our implementation; you may make a different choice.)
The writers will obtain the lock one at a time, each waiting for the previous writer to complete.
When all writers have completed, the entire set of sleeping readers are awakened and can then
Search WWH :
