I have revamped the code on the threads_rewrite branch for the mutex and read_write_mutex. The mutex code is now "swap-based", to eliminate the hand-off problems highlighted by Alexander Terekhov and Peter Dimov. It can be seen in CVS at boost/thread/win32/basic_timed_mutex.hpp on the thread_rewrite branch, or in the CVS web viewer at http://boost.cvs.sourceforge.net/boost/boost/boost/thread/win32/basic_timed_mutex.hpp?revision=1.1.2.6&view=markup&pathrev=thread_rewrite It keeps track of the "active count" of threads with an interest in the mutex, in order to try and avoid signalling the semaphore unnecessarily. The read_write_mutex code is based on ideas from the code offered by Peter Dimov and Cory Nelson. However, I have extended it to include upgradeable locks, and more closely mirror the interface proposed in the C++ Standard threading proposal N2094. At the moment it does not support try_ or timed_ variants. The code can be seen in CVS at boost/thread/win32/read_write_mutex.hpp on the thread_rewrite branch, or in the CVS web viewer at http://boost.cvs.sourceforge.net/boost/boost/boost/thread/win32/read_write_mutex.hpp?revision=1.1.2.6&view=markup&pathrev=thread_rewrite In all cases, the code tries to change state using compare-and-swap instructions. If the current state is blocking the state change (e.g. there is already a writer when we try to lock a reader), then the lock blocks on one of three win32 Event objects. The shared event is a manual reset event, so once readers are allowed access, they are all freed until a thread obtains an exclusive lock and resets the event. There is a limit on how many threads can have a shared/upgradeable lock (0x1fff), and how many can be waiting for a write lock (0xfff). Given the nature of read-write mutexes, this could easily be adjusted to allow more shared locks, and fewer waiting writers. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk