This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sbt
Recipients brian.curtin, kristjan.jonsson, loewis, pitrou, sbt, tim.golden
Date 2011-03-22.12:38:50
SpamBayes Score 4.7302306e-06
Marked as misclassified No
Message-id <>
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.
Date User Action Args
2011-03-22 12:38:51sbtsetrecipients: + sbt, loewis, pitrou, kristjan.jonsson, tim.golden, brian.curtin
2011-03-22 12:38:51sbtsetmessageid: <>
2011-03-22 12:38:50sbtlinkissue11618 messages
2011-03-22 12:38:50sbtcreate