Btw, the locktimeout.patch appears to have a race condition.  LeaveNonRecursiveMutex may SetEvent when there is no thread waiting (because a timeout just occurred, but the thread on which it happened is still somewhere around line #62 ).  This will cause the next WaitForSingleObject() to succeed, when it shouldn't.

It is this race between the timeout occurring, and the ability of us being able to register that in the lock's bookkeeping, that is the source of all the race problems with the timeout.  This is what prompted me to submit the condition variable version.