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
Activity
I'd like to work on this ，plz assign it to me :)
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.In addition, PyMutex itself still uses platform-dependent synchronization primitives, namely POSIX semaphore, pthread_cond+pthread_mutex, and CreateSemaphore on Windows
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.So changing the value of sys.thread_info.lock to "pymutex" makes its meaning ambiguous.
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.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/153263It has not been done, but Python 3.13 has been released in October 2024. IMO it's now too late to change it.
100% agree. That's why I proposed to revert this change in 3.15.
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.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.100% agree. That's why I proposed to revert this change in 3.15.
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).This is because it makes the value of sys.thread_info.lock technically 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 check sys.version_info and ignore sys.thread_info.lock.
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.- added a commit that references this issue
on Jul 7, 2026 - added a commit that references this issue
on Jul 19, 2026
Bug report
Bug description:
In GH-134747 and GH-141140,
sys.thread_info.lockwas changed to "pymutex". However, the implementation of_thread.Lockhad 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.RLockis the only synchronization primitive that depends onPyThread_type_lock. And in Python 3.14,_thread.RLockwas also changed to use the parking-lot-based_PyRecursiveMutex(67f6e08). However,sys.thread_info.lockremained 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 ofsys.thread_info.lockto "pymutex" makes its meaning ambiguous. In addition, PyMutex itself still uses platform-dependent synchronization primitives, namely POSIX semaphore,pthread_cond+pthread_mutex, andCreateSemaphoreon Windows (ref: https://github.com/python/cpython/blob/main/Python/parking_lot.c), precisely the same families of primitives previously reflected bysys.thread_info.lock.So I think the change to
sys.thread_info.lockshould be reverted to avoid confusing users.cc @vstinner
CPython versions tested on:
3.15
Operating systems tested on:
Linux, Windows
Linked PRs