Re: [Threads-devel] shared_mutex strategy

Subject: Re: [Threads-devel] shared_mutex strategy
From: Damien R (damienrg+list_at_[hidden])
Date: 2010-05-19 04:35:12

Anthony Williams wrote:
> If a reader gets the lock first, then more 
> readers will be allowed to get the lock until a waiting writer wakes and 
> registers its intent.

Yes, so in the worst case, only one reader will be able to read because
when the last reader unlocks the mutex, it notifies all waiters. For eg:
----
reader 0, 1, 2, 3 and writer 0 have the same priority
reader 0, 1, 2, 3 and writer 0 are waiting
last_reader notify all waiters
reader 0 call lock_shared and increment the number of readers
writer call lock(), so it change the state and wait until it is wake up
reader 1, 2, 3 call lock_shared() and wait because the state was changed
by the writer
reader 0 release lock change state, notify all waiters
----
Do you agree ?
> I am currently of the opinion that a reader-writer mutex is a bad idea 
> anyway since it actually hinders scaling --- it's a more complicated 
> beast than a simple mutex, so locking and unlocking takes longer, and it 
> forms a point of contention between threads. Every thread that acquires 
> a lock has to modify the mutex, even if all threads are readers, and 
> that means the cache line holding the mutex has to ping pong between 
> processors. In low contention scenarios a simple mutex is simpler, and 
> probably faster. In high contention scenarios you probably ought to 
> change the design to reduce the contention.
In my case, I have only one writer which writes very seldom and many
readers which often read.
So I keep your point in mind, but for now, I will implement my own mutex
based on your shared_mutex.
> The upshot of this is that I'm not going to change shared_mutex unless 
> it's actually broken.
Of course, I just wanted to be sure that I understand correctly what you
have done.