Re: [boost] read_write_mutex fundamentally broken in 1.33?

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-09-11 17:06:54

Anthony Williams <anthony_w.geo_at_[hidden]> writes:

> Howard Hinnant <hinnant_at_[hidden]> writes:
>
>> On Sep 10, 2005, at 5:53 PM, Anthony Williams wrote:
>>
>>> Attached is my latest offering, for win32. It still doesn't support 
>>> timed
>>> locks or anything beyond basic read/write/upgradeable locks. However, 
>>> it is
>>> faster than my earlier offering, since it uses interlocked operations 
>>> to avoid
>>> OS locks where possible.
>>>
>>> With each attempt to lock, then the locking thread will wait until it 
>>> can
>>> enter the "pending active" state. Only one thread is permitted in this 
>>> state
>>> at a time. Once in this state, the locking thread will wait until the 
>>> mutex
>>> state is correct for the lock to be acquired. The mutex state is 
>>> managed as a
>>> state flag, and a reader count.
>>
>> This looks like a significant improvement over your previous offering.  
>> But I'm still concerned.  But admittedly my analysis is incomplete, so 
>> please forgive me if I've got it wrong:
>>
>> With both the previous release and this one it looks like those threads 
>> waiting on upgradable or exclusive access are essentially polling if 
>> another thread already enjoys such access.  What I'm not seeing is a 
>> signal or condition variable upon which a thread sleeps after it enters 
>> the first gate and tries to acquire upgradable or exclusive access but 
>> discovers such access is not immediately available.  I fear the polling 
>> behavior will defeat the optimizations that read/write/upgradable exist 
>> for in the first place.  But I have not measured your code, so I could 
>> well be mistaken.
>
> You're half right! If the threads block on trying to enter a new state, then
> they wait on the mutex_state_sem. This semaphore is triggered every time a
> lock is released, and again if a waiting thread is awakened but cannot satisfy
> it's condition.
>
> This can lead to a thread polling, if it is the only waiting thread, because
> once it has been awakened, it will keep releasing the semaphore and
> reacquiring it until it's condition can be satisfied.
>
> Thanks for your comments, I guess there's work to be done!

Attached is a new implementation. It solves this problem by only releasing the
state-change semaphore if there is another thread waiting to change states. It
is possible that two waiting, but not satisfied, threads could therefore
repeatedly wake each other up.

I can't think of a better solution for now

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk