Repository navigation
RLock undocumented behavior in case of multiple acquire #70795
Description
Activity
smbrd commented
on Mar 22, 2016 smbrdmannequinMannequinAuthorThe number of acquisitions must be the same as the number of releases or else lock will not be released for other threads leading to deadlock. This is not mentioned in documentation.
First acquisition returns boolean and further acquisitions return 1. This is also not mentioned in documentation.
MojoVampire commented
on Mar 23, 2016 MojoVampiremannequinMannequinPer the docs ( https://docs.python.org/3/library/threading.html#rlock-objects ):
"To unlock the lock, a thread calls its release() method. acquire()/release() call pairs may be nested; only the final release() (the release() of the outermost pair) resets the lock to unlocked and allows another thread blocked in acquire() to proceed."
The docs aren't super clear on the return type, but they aren't so overly specified as to make returning either True or 1 incorrect; they use lowercase "true" to describe the return value, which doesn't *have* to mean True, just something that evaluates as truthy.
In 3.5 at least, it looks like both initial and subsequent acquires are all returning True, even when called without passing an argument; this actually violates the docs, which claim that not passing an argument means "There is no return value" (possibly only when there is contended acquisition, the wording is odd), when in fact a no-argument call returns True just like explicitly passing blocking as True.
ahxxm commented
on Jul 12, 2016 ahxxmmannequinMannequinAs seen from commit log, all return type are double back-quoted, this could be a rendering error.
I think this commit somehow makes it clear that RLock is a thread-level reentrant lock, some code example of suggested usage might be helpful though.
The RLock documentation is a bit more verbose than it needs to be (for instance, there is no reason to specify the "no args" case separately from the "blocking=True" case (since True is the default value of blocking).
The issue of balancing acquire/release calls is mentioned as Josh says, but could perhaps be stated more simply as well.
Working on this at PyCon 2023's cpython sprint.
Notes while trying to update the documentation:
First acquisition returns boolean and further acquisitions return 1. This is also not mentioned in documentation.
This longer seems to be true; acquire appears to always return
TrueorFalse. Also, the documentation has a statement:If more than one thread is blocked waiting until the lock is unlocked, only one at a time will be able to grab ownership of the lock. There is no return value in this case.
I have no idea what this means; why would it not return True or False? Confirmed w/ @gpshead it doesn't make sense. It's able to acquire the lock or not!
Here's a test program I have been fiddling with on Python 3.12:
import operator import time import threading LEVEL_LIMIT: int = 10 THREADS_MAX = 16 global_rlock = threading.RLock() def recursively_lock(level: int): """Test for RLock. Recusively call itself and observe the return value of acquire/release.""" tid = threading.get_ident() if level == LEVEL_LIMIT: print(f"{LEVEL_LIMIT=} reached, stopping recursion") return print(f"Started {tid=}") rv = global_rlock.acquire(blocking=False) if rv: print(f"RLock acquire()={rv} at {level=} for {tid=}") time.sleep(0.1) recursively_lock(level + 1) rv = global_rlock.release() print(f"RLock release()={rv} at {level=}") else: print(f"Unable to acquire lock for {tid=} {rv=}") if __name__ == "__main__": threads: list[threading.Thread] = [] for i in range(0, THREADS_MAX): threads.append(threading.Thread(target=recursively_lock, args=(0,))) for t in threads: t.start() # map(operator.methodcaller("start"), threads) map(operator.methodcaller("join"), threads) print("Hello world")
I've been unable to replicate the case where None is returned, or acquire not returning True or False.
- added a commit that references this issue
on Apr 25, 2023 The old docs mention that
acquirereturnsNone, this seems not the case looking atrlock_acquire's implementation https://github.com/python/cpython/blob/main/Modules/_threadmodule.c#L355Double checked by gpshead
- added a commit that references this issue
on Apr 25, 2023
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs