Skip to content

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

@GalaxySnail

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    type-bugAn unexpected behavior, bug, or error

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions