[issue11618] Locks broken wrt timeouts on Windows
sbt
report at bugs.python.org
Tue Mar 22 13:41:59 CET 2011
sbt <shibturn at gmail.com> added the comment:
krisvale wrote:
----
So, I suggest a change in the comments: Do not claim that the value is never an underestimate, and explain how falsely returning a WAIT_TIMEOUT is safe and only occurs when the lock is heavily contented.
Sorry for being so nitpicky but having this stuff correct is crucial.
----
Nitpickiness is a necessity ;-)
I've done a new version which replaces the "meaningless" racy test on line 50 with the simpler test
else if (mutex->timeouts == 0)
As with the old "meaningless" test, if the test succeeds then there must at least have been very recent conention for the lock, so timing out is reasonable.
Also the new patch only considers rezeroing mutex->timeouts if we acquire the lock on the slow path.
The patch contains more comments than before.
----------
Added file: http://bugs.python.org/file21336/locktimeout3.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11618>
_______________________________________
More information about the Python-bugs-list
mailing list