This PR adds atomic loads in the slow path ofPyMutex to increase the number of lock acquisitions per second that threads can make on a shared mutex.

The tricky part here is to avoid degrading the performance when the lock is highly contended; that is, when many threads are trying to acquire the mutex at a high frequency. This is because the current strategy of never reloading the mutex's state is, maybe counter-intuitively, the best strategy: avoid disturbing the thread that currently holds the mutex.

I've run thelockbench script to assess the performance using the following two scenarios, which were suggested by@colesbury:

• low contention:

./python.exe Tools/lockbench/lockbench.py --work-inside 5 --work-outside 50 --num-locks 24 --acquisitions 3 --random-locks

• high contention:

./python.exe Tools/lockbench/lockbench.py --work-inside 5 --work-outside 5

The results are from my M4 MacBook, and Python was compiled with--disable-gil --enable-optimizations --with-lto.

The different lines below represent different reloading strategies:

• old:main
• unconditional: remove theif statement at line 107
• RELOAD_SPIN_COUNT = ...: tweak the value at line 30

TheRELOAD_SPIN_COUNT = ... strategies also pseudo-randomize the reload recurrence by having each thread add its own thread-id to the counter. On my machine this nets a ~15/20% improvement over the same strategy, without this pseudo-randomization.

And here's the comparison betweenmain and this PR, which picks theRELOAD_SPIN_COUNT = 3 strategy:

The fact that the high contention case shows as an improvement in this chart is misleading: I'd say it's in the noise range.

• Issue:Non-blocking_PyMutex_LockTimed spins and may fail unnecessarily in no-GIL builds #135871