sbt <shibt...@gmail.com> added the comment:
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).
----------
_______________________________________
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
