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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-10-30 19:41:27

Roland Schwarz wrote:
> Having tried to catch up with the last RW-lock discussion I am
> left wondering what is the conclusion of the discussion.
>
> In thread_rewrite there is an implementation from Anthony.
> This however currently is only for windows so far, correct?

POSIX already has a rwlock; it's a mandatory part of the threading support 
(despite having its own feature test macro). A reimplementation could be 
necessary if the Boost version supports upgradable locks, though.

> As I do understand the problem (please correct me if I am wrong)
> there is not a single reader-writer problem, but three:
>
> 1) reader-priority rw-access
> 2) writer-priority rw-access
> 3) starvation free rw-access
>
> which of these three cases applies is in the application domain
> and not in the domain of the library implementation.

I can't imagine a use case for a reader-priority rwlock; it seems to me that 
an rwlock is simply not the correct synchronization primitive in such a 
case. Linux NPTL seems to supply one, though. So I may be wrong.

I think that we now have a fairly good idea of how a rwlock is supposed to 
operate, and that our understanding coincides with the POSIX specification, 
under the assumption that the threads have equal priorities. In a nutshell, 
the rule is: 'rdlock' succeeds in obtaining a read lock if and only if no 
thread has obtained a write lock and there is no thread blocked in 'lock'. 
In my opinion, we only need to do one version, and do it right.

> However, since rw-mutices can be made of a mutex and some condition
> variables, shouldn't we follow the old principle of getting it
> correct first and optimize later?

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.

Viewed in this light, a read/write mutex that is slower than an ordinary 
mutex for the typical use cases is - IMO - not really worth having in the 
library.

> 0) Decide if we want the current (broken) version in 1.34.
>    Please note that this is URGENT. (A previous poll about this
>    interestingly did not get answered by anyone.)

We've never wanted a broken version of any component in any release. :-)