Feature or enhancement

The multiprocessing SemLock code maintains an internal count field. When operating as a recursive mutex, count is the number of times the thread has acquired the mutex (i.e., 0, 1, .. N). When operating as a semaphore, count is often 0 or 1, but can be negative if the SemLock is initialized with maxvalue > 1

The modification of count is not thread-safe without the GIL within the process. Note that the count field is not shared across processes, unlike the underlying sem_t or HANDLE.

In particular, the modification of count after the semaphore is released is not thread-safe without the GIL:

I think this is the source of deadlocks when running test_multiprocessing_forkserver.test_processes with the GIL disabled.

Linked PRs

• gh-117435: Make SemLock thread-safe in free-threaded build #117436