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-21.18:19:08
SpamBayes Score 2.198929e-08
Marked as misclassified No
Message-id <>
sbt wrote:
I see your point.  Still, I think we still may have a flaw:  The statement that (owned-timeouts) is never an under-estimate isn't true on modern architectures, I think.  The order of the atomic decrement operations in the code means nothing and cannot be depended on to guarantee such a claim:  The thread doing the reading may see the individual updates in any order, and so the estimate may be an over- or an underestimate.

The interlocked functions act as read (and write) memory barriers, so mutex->timeout is never any staler than the value of owned obtained from the preceeding interlocked function call.  As you say my claim that (owned-timeout) is never an underestimate is dubious.  But the only time I use this quantity is in this bit:

        else if (owned - mutex->timeouts != -1)     /* harmless race */
            return WAIT_TIMEOUT ;

If this test gives a false negative we just fall through to the slow path (no problem).  If we get a false positive it is because one of the two following races happened:

1) Another thread just got the lock: letting the non-blocking acquire fail is clearly the right thing to do.

2) Another thread just timed out: this means that a third thread must have held the lock up until very recently, so allowing a non-blocking acquire to fail is entirely reasonable (even if WaitForSingleObject() might now succeed).
Date User Action Args
2011-03-21 18:19:09sbtsetrecipients: + sbt, loewis, pitrou, kristjan.jonsson, tim.golden, brian.curtin
2011-03-21 18:19:09sbtsetmessageid: <>
2011-03-21 18:19:08sbtlinkissue11618 messages
2011-03-21 18:19:08sbtcreate