Bug report

Bug description:

There is a race between when Thread._tstate_lock is released¹ in Thread._wait_for_tstate_lock() and when Thread._stop() asserts² that it is unlocked. Consider the following execution involving threads A, B, and C:

1. A starts.
2. B joins A, blocking on its _tstate_lock.
3. C joins A, blocking on its _tstate_lock.
4. A finishes and releases its _tstate_lock.
5. B acquires A's _tstate_lock in _wait_for_tstate_lock(), releases it, but is swapped out before calling _stop().
6. C is scheduled, acquires A's _tstate_lock in _wait_for_tstate_lock() but is swapped out before releasing it.
7. B is scheduled, calls _stop(), which asserts that A's _tstate_lock is not held. However, C holds it, so the assertion fails.

The race can be reproduced³ by inserting sleeps at the appropriate points in the threading code. To do so, run the repro_join_race.py from the linked repo.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux