gh-114203: Optimise simple recursive critical sections #128126
Conversation
…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.
should be relatively rare and we don't want to burden the fastest path.
gpshead
left a comment
There was a problem hiding this comment.
I do wonder if there might be additional optimization opportunities along these lines, but that should be future work if ever needed.
That's true for pretty much 100% of the work in free-threaded Python right now 😅 In addition to "I don't know if this fixes all thread-unsafety, but we can look at it later." :P |
|
FWIW, Sam ran benchmarks on the latest version, which seems like a very clear positive ("Geometric mean: 1.024x faster (HPT: reliability of 99.39%, 1.00x faster at 99th %ile)"; no worrying regressions, some loss in some benchmarks but a small win in enough that it's either noise or an overall good thing, massive improvement in a few benchmarks): https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20241220-3.14.0a3%2B-b28153d-NOGIL/bm-20241220-vultr-x86_64-Yhg1s-optimise_recursive_c-3.14.0a3%2B-b28153d-vs-base.svg |
…128126) 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.
Add a fast path to (single-mutex) critical section locking iff the mutex is already held by the top-most critical section of this thread. This can matter a lot for indirectly recursive critical sections without intervening critical sections.