Re: [boost] [threads] read_write_mutex performance

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.

-Howard