sbt <shibt...@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/file21335/locktimeout3.patch
_______________________________________
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
