Subject: Re: [Threads-devel] shared_mutex strategy
From: Jérémy Coulon (jeremy.coulon_at_[hidden])
Date: 2010-05-19 13:53:19
Le 19/05/2010 10:43, Anthony Williams a écrit :
> On 19/05/10 09:35, Damien R wrote:
>> 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 ?
> Yes, that's a possible outcome. It does mean that the writer only has
> to wait for the one reader before it gets another shot at acquiring
> the lock, rather than waiting for all pending readers should a reader
> acquire the lock.
I am also interested in the current reader/writer lock behaviour.
I don't understand what you mean.
For example, let's consider 2 readers and 1 writer.
At initialisation, the lock is available to any thread.
First, Reader0 calls lock_shared() and enters the critical section.
Then Writer0 calls lock() and waits because Reader0 did not release the
Then Reader1 calls lock_shared() and enters the critical section because
no writer currently owns the lock.
Then, Reader0 release the lock but Reader1 is still in the critical section.
In this situation, if you have N readers, the writer will wait forever
and starve because there may always be 1 reader in the critical section.
I tried the previous example and it is the current behaviour !
What do you think ?