Boost logo

Boost :

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

> 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. :-)

Boost list run by bdawes at, gregod at, cpdaniel at, john at