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