Re: [boost] [thread] Roadmap for RW locks ?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-10-31 08:46:38

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.