Tim Peters added the comment:
They certainly should _not_ be swapped, as explained clearly in the message
following the one you referenced. For the first half:
if self._lock.acquire(0):
succeeds if and only if the lock is not held by _any_ thread at the time. In
that case, the lock is _acquired_ as a side-effect of performing the test, and
the code goes on to restore the lock again to its initially unacquired state,
and (correctly) return False:
self._lock.release()
return False
The second half of the code is certainly wrong:
else:
return True
The docs state:
# Return True if lock is owned by current_thread.
but the code actually returns True if the lock is currently owned by _any_
thread. All that is also explained in the thread you pointed at.
However, I don't see any possibility of fixing that. There is simply no way to
know, for an arbitrary "lock-like" object, which thread owns it.
Indeed, on Windows it's not even possible for a threading.Lock. For example
(here under Python3, but I'm sure it's the same under Python2):
>>> import threading as th
>>> lock = th.Lock()
>>> c = th.Condition(lock)
>>> def hmm():
... print("is_owned:", c._is_owned())
...
>>> t = th.Thread(target=hmm)
>>> t.start()
is_owned: False
>>> lock.acquire()
True
>>> t = th.Thread(target=hmm)
>>> t.start()
is_owned: True
Note that the last line showed True despite that the lock is _not_ owned by the
thread doing the print - it's owned by the main program thread. That's because
threading.Lock._is_owned doesn't exist under Windows, so it's falling into the
second case of the Condition._is_owned() implementation at issue here.
Also note that if the True and False cases were swapped, _none_ of the output
would make any sense at all ;-)
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue20247>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
