Repository navigation
sys.thread_info.lock was changed to "pymutex" in 3.15, even though _thread.Lock had already switched to PyMutex in 3.14 and 3.13.1 #152798
Description
Bug report
Bug description:
In GH-134747 and GH-141140, sys.thread_info.lock was changed to "pymutex". However, the implementation of _thread.Lock had already been changed to use PyMutex in Python 3.14 (fca5529), and was backported to 3.13.1 (20242a4). In Python 3.13.1 and later, _thread.RLock is the only synchronization primitive that depends on PyThread_type_lock. And in Python 3.14, _thread.RLock was also changed to use the parking-lot-based _PyRecursiveMutex (67f6e08). However, sys.thread_info.lock remained unchanged: it's still "semaphore" on Linux and None on Windows in Python 3.14.
GH-134747 only changed the implementation of PyThread_type_lock, which is irrelevant to synchronization primitives in the threading module. So changing the value of sys.thread_info.lock to "pymutex" makes its meaning ambiguous. In addition, PyMutex itself still uses platform-dependent synchronization primitives, namely POSIX semaphore, pthread_cond+pthread_mutex, and CreateSemaphore on Windows (ref: https://github.com/python/cpython/blob/main/Python/parking_lot.c), precisely the same families of primitives previously reflected by sys.thread_info.lock.
So I think the change to sys.thread_info.lock should be reverted to avoid confusing users.
cc @vstinner
CPython versions tested on:
3.15
Operating systems tested on:
Linux, Windows
Activity
Wojusensei commentedon Jul 4, 2026
I'd like to work on this ，plz assign it to me :)
IvyXu420 commentedon Jul 7, 2026
vstinner commentedon Jul 7, 2026
I suggest closing this issue. Or if something is done, it should be to only enhance the documentation.
Well,
sys.thread_info.lockcould be changed to'pymutex'in Python 3.13, since_thread.allocate_lock()was modified to usePyMutexinternally. It has not been done, but Python 3.13 has been released in October 2024. IMO it's now too late to change it.That's correct, but I prefer the short string
'pymutex'to refer toPyMutex. If someone needs more details about PyMutex, they can dig into the code, as you did.I don't see how it's confusing. Python now uses PyMutex for
threading.Lock,threading.RLockand for the C APIPyThread_allocate_lock(). It's used everywhere.Wojusensei commentedon Jul 7, 2026
thanks for the confirmation and I've opened a PR to update the documentation without changing codes as u suggested：
https://github.com/python/cpython/pull/153263
GalaxySnail commentedon Jul 7, 2026
100% agree. That's why I proposed to revert this change in 3.15.
This is because it makes the value of
sys.thread_info.locktechnically wrong in 3.13 and 3.14. Users can't rely on this value to determine which lock implementation is actually used; instead, they have to checksys.version_infoand ignoresys.thread_info.lock.vstinner commentedon Jul 7, 2026
That's not what I'm saying. I don't suggest a revert. Changing
sys.thread_infoin 3.15 was a good thing. I'm just saying that it's too late to changesys.thread_infoin 3.13 and 3.14 since they are already released (a change can break users relying in the exact value).I don't consider that it's a big deal.
sys.thread_infois mostly here to help debugging CPython issues. I don't see why someone would really bother how locks are implemented in Python.gh-152798: update sys.thread_info.lock documentation to match impleme…
[3.15] gh-152798: update sys.thread_info.lock documentation to match …