From: Howard Hinnant (hinnant_at_[hidden])
Date: 2005-09-10 18:33:51
On Sep 10, 2005, at 5:53 PM, Anthony Williams wrote:
> Attached is my latest offering, for win32. It still doesn't support
> 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
> enter the "pending active" state. Only one thread is permitted in this
> at a time. Once in this state, the locking thread will wait until the
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk