Bug report

Bug description:

There is a race between whenThread._tstate_lock is released¹ inThread._wait_for_tstate_lock() and whenThread._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 therepro_join_race.py from the linked repo.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux