mirror of
https://github.com/python/cpython.git
synced 2025-09-21 08:00:37 +00:00
0c89056fe5
PyMutex is a one byte lock with fast, inlineable lock and unlock functions for the common uncontended case. The design is based on WebKit's WTF::Lock. PyMutex is built using the _PyParkingLot APIs, which provides a cross-platform futex-like API (based on WebKit's WTF::ParkingLot). This internal API will be used for building other synchronization primitives used to implement PEP 703, such as one-time initialization and events. This also includes tests and a mini benchmark in Tools/lockbench/lockbench.py to compare with the existing PyThread_type_lock. Uncontended acquisition + release: * Linux (x86-64): PyMutex: 11 ns, PyThread_type_lock: 44 ns * macOS (arm64): PyMutex: 13 ns, PyThread_type_lock: 18 ns * Windows (x86-64): PyMutex: 13 ns, PyThread_type_lock: 38 ns PR Overview: The primary purpose of this PR is to implement PyMutex, but there are a number of support pieces (described below). * PyMutex: A 1-byte lock that doesn't require memory allocation to initialize and is generally faster than the existing PyThread_type_lock. The API is internal only for now. * _PyParking_Lot: A futex-like API based on the API of the same name in WebKit. Used to implement PyMutex. * _PyRawMutex: A word sized lock used to implement _PyParking_Lot. * PyEvent: A one time event. This was used a bunch in the "nogil" fork and is useful for testing the PyMutex implementation, so I've included it as part of the PR. * pycore_llist.h: Defines common operations on doubly-linked list. Not strictly necessary (could do the list operations manually), but they come up frequently in the "nogil" fork. ( Similar to https://man.freebsd.org/cgi/man.cgi?queue) --------- Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com> |
||
|---|---|---|
| .. | ||
| c_analyzer | ||
| c_common | ||
| c_parser | ||
| cpython | ||
| distutils | ||
| c-analyzer.py | ||
| check-c-globals.py | ||
| must-resolve.sh | ||
| README | ||
| table-file.py | ||
| TODO | ||
####################################### # C Globals and CPython Runtime State. CPython's C code makes extensive use of global variables. Each global falls into one of several categories: * (effectively) constants (incl. static types) * globals used exclusively in main or in the REPL * freelists, caches, and counters * process-global state * module state * Python runtime state The ignored-globals.txt file is organized similarly. Of the different categories, the last two are problematic and generally should not exist in the codebase. Globals that hold module state (i.e. in Modules/*.c) cause problems when multiple interpreters are in use. For more info, see PEP 3121, which addresses the situation for extension modules in general. Globals in the last category should be avoided as well. The problem isn't with the Python runtime having state. Rather, the problem is with that state being spread throughout the codebase in dozens of individual globals. Unlike the other globals, the runtime state represents a set of values that are constantly shifting in a complex way. When they are spread out it's harder to get a clear picture of what the runtime involves. Furthermore, when they are spread out it complicates efforts that change the runtime. Consequently, the globals for Python's runtime state have been consolidated under a single top-level _PyRuntime global. No new globals should be added for runtime state. Instead, they should be added to _PyRuntimeState or one of its sub-structs. The check-c-globals script should be run to ensure that no new globals have been added: python3 Tools/c-analyzer/check-c-globals.py You can also use the more generic tool: python3 Tools/c-analyzer/c-analyzer.py If it reports any globals then they should be resolved. If the globals are runtime state then they should be folded into _PyRuntimeState. Otherwise they should be added to ignored-globals.txt.