Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-10-31 11:49:15

Peter Dimov wrote:
> Have you ever encountered a situation in which you needed an implementation
> that could starve readers or writers?

Al tough recognizing that this question likely is meant as a rhetorical
one, I do not think that it matters whether I encountered such a
situation. But I can easily envision an example:
Garbage collection: one class of threads that use a container in a way
that strongly interferes with the garbage collector. The first class
are the "readers" and the garbage collector is the writer. The "readers"
should be able to hold off the garbage collector with priority.

I have to admit that this example is somewhat uncorrelated to a
rw-lock since the "readers" likely are not only performing ro access.

But perhaps I have a different concpetion about rw locks. To me they
are a special case of the more general group locks.

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

Ok, understood, but there are cases.

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

Agreed. But what is wrong on providing the other scheduling strategies
as well? Do you think that the current interface does prohibit
And what is wrong to also have a generic variant for platforms where the
optimization has not yet been carried out?

If you think the interface is lacking, could you please tell in which


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