|
Boost : |
From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-09-10 16:53:41
Matt Hurd <matt.hurd_at_[hidden]> writes:
>> On 10/09/05, russell_at_[hidden] <russell_at_[hidden]> wrote:
> <snip>
>> How should we proceed from here? Should the community come up with a list
>> of alternative implementations that could be evaluated and used as a
>> starting point? Or do we need to go back a step further and decide what
>> types of mutexes or primitives are actually desired?
>
> A candidate solution should be around in a few daze I hope.
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.
Anthony
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk