[issue11618] Locks broken wrt timeouts on Windows
sbt
report at bugs.python.org
Mon Mar 21 17:34:59 CET 2011
sbt <shibturn at 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 <report at bugs.python.org>
<http://bugs.python.org/issue11618>
_______________________________________
More information about the Python-bugs-list
mailing list