Locks, Conditions, and Events

Both objects are mutual-exclusion primitives from the `threading` module, and both support the context-manager protocol, so the idiomatic use of either is `with the_lock:` rather than a hand-written `acquire()`/`release()` pair. The difference is entirely about **ownership and re-entry**. ### threading.Lock — a binary flag with no owner A `threading.Lock` has exactly two states. `acquire()` returns `True` when it flips the lock from unlocked to locked; if the lock is already locked, the calling thread blocks until someone releases it. There is no record of *who* locked it. Two consequences follow directly: * **It is not reentrant.** If the thread that holds the lock calls `acquire()` again, it blocks waiting for itself, and nothing will ever release it. That is a self-deadlock, and it presents in production as one thread parked forever with no exception and no log line. * **Any thread may release it.** Because the lock has no owner, a `release()` from an unrelated thread is accepted. Releasing a lock that is *not* held raises `RuntimeError`, but releasing one held by a different thread does not. `acquire()` takes two useful arguments. `acquire(blocking=False)` returns `False` immediately instead of waiting, which is the safe way to *test* a lock — note that `locked()` is only a snapshot and is racy the moment it returns. `acquire(timeout=0.5)` waits at most that long and returns `False` if it gives up. Both are how you avoid an unbounded park in code that must stay responsive. ### threading.RLock — an owner plus a counter A `threading.RLock` stores the identity of the owning thread and a recursion depth. When the owner acquires it again, the depth increments and the call returns immediately. When a *different* thread acquires it, that thread blocks exactly as it would on a `Lock`. `release()` decrements the depth; the lock only becomes available to other threads when the depth reaches zero. Only the owner may release it — a release from a non-owning thread raises `RuntimeError`. The classic reason to want one is a class whose public methods each guard themselves and sometimes call one another: ```python import threading class Ledger: def __init__(self): self._lock = threading.RLock() self._entries = [] def add(self, entry): with self._lock: self._entries.append(entry) def add_batch(self, entries): with self._lock: for entry in entries: self.add(entry) # re-enters the same lock ``` With a plain `Lock`, `add_batch` would hang on the first inner `add`. The usual alternative is to split each guarded public method into a thin locking wrapper plus an unlocked `_add_locked` helper that assumes the lock is already held — more code, but it documents the locking discipline explicitly and keeps the cheaper primitive. ### Which to reach for Default to `Lock`. It is the simpler object, it is slightly faster, and its self-deadlock on re-entry is a *feature* during development: it surfaces a call graph you did not know re-entered a critical section. Reach for `RLock` when re-entry is genuinely part of the design and restructuring the call graph would be worse. Treat a codebase that uses `RLock` everywhere as a smell — it usually means nobody knows which functions hold what. Two details interviewers like to probe. First, an `RLock` acquired twice needs two releases; a single `release()` in a `finally` after two acquires leaves the lock held forever, which is the mirror image of the self-deadlock. Second, `threading.Condition()` constructed with no arguments creates an `RLock` internally, which is why `with cond:` nests safely. Finally, none of this changes because CPython has a global interpreter lock. The GIL serializes bytecode execution; it does not make a multi-step read-modify-write atomic, because a thread switch can land between bytecodes. On the free-threaded build — officially supported as of Python 3.14 — there is not even that incidental serialization, so explicit locks are the only thing standing between you and interleaved updates.