summaryrefslogtreecommitdiffstats
path: root/Python/critical_section.c
Commit message (Collapse)AuthorAgeFilesLines
* gh-114203: Optimise simple recursive critical sections (#128126)T. Wouters2024-12-231-7/+17
| | | | | | | Add a fast path to (single-mutex) critical section locking _iff_ the mutex is already held by the currently active, top-most critical section of this thread. This can matter a lot for indirectly recursive critical sections without intervening critical sections.
* gh-119344: Make critical section API public (#119353)Sam Gross2024-06-211-29/+77
| | | | | | | | | | This makes the following macros public as part of the non-limited C-API for locking a single object or two objects at once. * `Py_BEGIN_CRITICAL_SECTION(op)` / `Py_END_CRITICAL_SECTION()` * `Py_BEGIN_CRITICAL_SECTION2(a, b)` / `Py_END_CRITICAL_SECTION2()` The supporting functions and structs used by the macros are also exposed for cases where C macros are not available.
* gh-117511: Make PyMutex public in the non-limited API (#117731)Sam Gross2024-06-201-1/+1
|
* gh-111569: Implement Python critical section API (gh-111571)Sam Gross2023-11-081-0/+100
Critical sections are helpers to replace the global interpreter lock with finer grained locking. They provide similar guarantees to the GIL and avoid the deadlock risk that plain locking involves. Critical sections are implicitly ended whenever the GIL would be released. They are resumed when the GIL would be acquired. Nested critical sections behave as if the sections were interleaved.