Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2005-04-24 18:52:38

On Apr 24, 2005, at 3:34 PM, Peter Dimov wrote:

> Ion Gaztañaga wrote:
>> For what I've seen in code, read_write_mutex has a lot of options
>> regarding reader/writer priorities and for that uses conditions and
>> mutexes to offer that functionality. The overhead is bigger than
>> mutexes, but I think the critical section you have chosen is very
>> small, and where read_writer_mutex shines is when you have to lock
>> expensive operations (lookups for example, in data-bases) with lots
>> of readers. In that case, a mutex would
>> serialize all, but read_writer_mutex would allow concurrent
>> readers.
> Yes. However my suspicion is that read/write locks only speed up code
> that has been written in an inefficient (MT-unfriendly) way. For high
> performance, critical regions need to be as small and quick as
> possible, and read/write locks appear to target the case where the
> critical regions are relatively large and slow.

I suspect that there will always be cases where tiny critical regions
are just not practical, where writers are rare compared to readers, and
thus where read-write locks are a good performance win, especially on a
multi-processor architecture.

That being said, it occurred to me as I ran your test on the
Metrowerks::threads lib (and got similar results) that the first thing
we (and boost) do on read_lock is lock a mutex so that the read_write
mutex state is protected while updating it. I haven't even begun to
figure it out, but I strongly suspect that a lock-free algorithm for
read_lock could be developed. This could reduce the need for
read_write mutex to lock an internal mutex, thus expanding (perhaps
significantly) the contexts where read-write locks make sense.


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