[issue20247] Condition._is_owned is wrong
Tim Peters
report at bugs.python.org
Wed Jan 15 03:56:20 CET 2014
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 <report at bugs.python.org>
<http://bugs.python.org/issue20247>
_______________________________________
More information about the Python-bugs-list
mailing list