
Roland Schwarz wrote:
Peter Dimov wrote:
In my opinion, we only need to do one version, and do it right.
I am not yet convinced.
Altough Wikipedia is not a citable resource: http://en.wikipedia.org/wiki/Readers-writers_problem
Butenhof's example in "Programming with Posix Threads".
Bill Kempfs Implementation.
Several sites I looked up in the net.
Have you ever encountered a situation in which you needed an implementation that could starve readers or writers? (Note that it is possible for a no-starvation implementation to favor readers or writers, but this is different.)
The problem in this case is that a rwlock is almost purely a performance optimization. It is generally not used for its semantics (although I can imagine a few use cases for them); a mutex is replaced with a rwlock in an attempt to increase reader performance, preferably without slowing down writers to a standstill.
???
Sorry I absolutely cannot understand the previous. A pure performance optimization? I always thought it was mainly used because of its semantics: You are letting multiple readers access at the same time: This is the main source of performance gain.
There are very few cases in which an rwlock is used for its semantics; by this I mean that the rwlock cannot be replaced by a mutex without changing the correctness of the code. In the majority of cases, a resource is protected by a rwlock not because the program logic demands reader parallelism, but because there is potentially a performance advantage in allowing reader parallelism. Therefore, if by replacing a rwlock with a mutex you are realizing a performance gain, this rwlock implementation has a negative contribution to the value of the library, because it lures users into what they believe to be an optimization, but is actually a pessimization. False advertising and all that.