sbt <shibt...@gmail.com> added the comment: > 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.
I believe the lock is still in a consistent state. If this race happens and SetEvent() is called then we will must have mutex->owned > -1 because the timed out waiter is still counted by mutex->owned. This prevents the tests involving interlocked functions from giving true. Thus WaitForSingleObject() is the ONLY way for a waiter to get the lock. In other words, as soon as a timeout happens the fast "interlocked path" gets blocked. It is only unblocked again after a call to WaitForSingleObject() succeeds: then the thread which now owns the lock fixes mutex->owned using mutex->timeouts and the interlocked path is operational again (unless another timeout happens). I can certainly understand the desire to follow the KISS principle. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11618> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
