summaryrefslogtreecommitdiffstats
path: root/Python/parking_lot.c
Commit message (Collapse)AuthorAgeFilesLines
* gh-117657: Avoid `sem_clockwait` in TSAN (#119915)Sam Gross2024-06-031-1/+1
| | | | The `sem_clockwait` function is not currently instrumented, which leads to false positives.
* gh-110850: Remove _PyTime_TimeUnchecked() function (#118552)Victor Stinner2024-05-051-5/+12
| | | | | | | | | | | | | Use the new public Raw functions: * _PyTime_PerfCounterUnchecked() with PyTime_PerfCounterRaw() * _PyTime_TimeUnchecked() with PyTime_TimeRaw() * _PyTime_MonotonicUnchecked() with PyTime_MonotonicRaw() Remove internal functions: * _PyTime_PerfCounterUnchecked() * _PyTime_TimeUnchecked() * _PyTime_MonotonicUnchecked()
* gh-117657: Quiet TSAN warnings about remaining non-atomic accesses of ↵mpage2024-04-231-1/+2
| | | | | `tstate->state` (#118165) Quiet TSAN warnings about remaining non-atomic accesses of `tstate->state`
* gh-108724: Fix _PySemaphore_Wait call during thread deletion (#116483)Sam Gross2024-03-081-4/+6
| | | | | | | | | In general, when `_PyThreadState_GET()` is non-NULL then the current thread is "attached", but there is a small window during `PyThreadState_DeleteCurrent()` where that's not true: tstate_delete_common() is called when the thread is detached, but before current_fast_clear(). Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
* gh-110850: Rename internal PyTime C API functions (#115734)Victor Stinner2024-02-201-4/+4
| | | | | | | | | | | | | | | | | Rename functions: * _PyTime_GetSystemClock() => _PyTime_TimeUnchecked() * _PyTime_GetPerfCounter() => _PyTime_PerfCounterUnchecked() * _PyTime_GetMonotonicClock() => _PyTime_MonotonicUnchecked() * _PyTime_GetSystemClockWithInfo() => _PyTime_TimeWithInfo() * _PyTime_GetMonotonicClockWithInfo() => _PyTime_MonotonicWithInfo() * _PyTime_GetMonotonicClockWithInfo() => _PyTime_MonotonicWithInfo() Changes: * Remove "typedef PyTime_t PyTime_t;" which was "typedef PyTime_t _PyTime_t;" before a previous rename. * Update comments of "Unchecked" functions. * Remove invalid PyTime_Time() comment.
* gh-110850: Cleanup pycore_time.h includes (#115724)Victor Stinner2024-02-201-4/+5
| | | | | <pycore_time.h> include is no longer needed to get the PyTime_t type in internal header files. This type is now provided by <Python.h> include. Add <pycore_time.h> includes to C files instead.
* gh-110850: Replace _PyTime_t with PyTime_t (#115719)Victor Stinner2024-02-201-6/+6
| | | | | Run command: sed -i -e 's!\<_PyTime_t\>!PyTime_t!g' $(find -name "*.c" -o -name "*.h")
* gh-114944: Fix race between `_PyParkingLot_Park` and ↵mpage2024-02-051-2/+2
| | | | | | | | | | | | | | | | | | | | | `_PyParkingLot_UnparkAll` when handling interrupts (#114945) Fix race between `_PyParkingLot_Park` and `_PyParkingLot_UnparkAll` when handling interrupts There is a potential race when `_PyParkingLot_UnparkAll` is executing in one thread and another thread is unblocked because of an interrupt in `_PyParkingLot_Park`. Consider the following scenario: 1. Thread T0 is blocked[^1] in `_PyParkingLot_Park` on address `A`. 2. Thread T1 executes `_PyParkingLot_UnparkAll` on address `A`. It finds the `wait_entry` for `T0` and unlinks[^2] its list node. 3. Immediately after (2), T0 is woken up due to an interrupt. It then segfaults trying to unlink[^3] the node that was previously unlinked in (2). To fix this we mark each waiter as unparking before releasing the bucket lock. `_PyParkingLot_Park` will wait to handle the coming wakeup, and not attempt to unlink the node, when this field is set. `_PyParkingLot_Unpark` does this already, presumably to handle this case.
* gh-112606: Use pthread_cond_timedwait_relative_np() in parking_lot.c when ↵Matt Prodani2024-01-301-1/+5
| | | | | | | available (#112616) Add a configure define for HAVE_PTHREAD_COND_TIMEDWAIT_RELATIVE_NP and replaces pthread_cond_timedwait() with pthread_cond_timedwait_relative_np() for relative time when supported in semaphore waiting logic.
* gh-112606: Use sem_clockwait with monotonic time when supported in ↵Matt Prodani2023-12-061-2/+11
| | | | parking_lot.c (gh-112733)
* gh-108724: Add PyMutex and _PyParkingLot APIs (gh-109344)Sam Gross2023-09-191-0/+370
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>