Boost logo

Boost :

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 Williams
Software Developer
Just Software Solutions Ltd

Boost list run by bdawes at, gregod at, cpdaniel at, john at