gh-158336: Fix race in lock_tests test_set_and_clear - #158337
matthiasgoergens wants to merge 1 commit into
Conversation
test_set_and_clear started N threads calling event.wait() and then slept 50 ms (wait_threads_blocked) before calling event.set() and event.clear(). If a thread only reached wait() after clear(), it saw the flag unset and blocked for LONG_TIMEOUT, and Bunch.__exit__ gave up after SHORT_TIMEOUT. This happened on CI in the TSan free-threading job. Wait until all N threads are in the Condition's waiter list instead. Condition.wait() appends the waiter while holding the lock, and notify_all() releases every waiter in the list, so each of those threads is guaranteed to be woken by set(). On a TSan free-threading debug build, pinned to 2 CPUs shared with 4 busy-looping processes, the test failed in 9 of 40 runs before this change and 0 of 40 after.
vstinner
left a comment
vstinner
left a comment
There was a problem hiding this comment.
I hate wait_threads_blocked() sleep, it's a bad synchronization primitive!
| # Wait until all threads are registered as waiters in | ||
| # event.wait(). A thread that only reaches wait() after set() | ||
| # and clear() would block until the timeout, so a fixed sleep | ||
| # is not enough on a busy machine. |
There was a problem hiding this comment.
I don't think that the second part of the comment is useful.
| # Wait until all threads are registered as waiters in | |
| # event.wait(). A thread that only reaches wait() after set() | |
| # and clear() would block until the timeout, so a fixed sleep | |
| # is not enough on a busy machine. | |
| # Wait until all threads are registered as waiters in | |
| # event.wait(). |
| # and clear() would block until the timeout, so a fixed sleep | ||
| # is not enough on a busy machine. | ||
| for _ in support.sleeping_retry(support.SHORT_TIMEOUT): | ||
| if len(event._cond._waiters) >= N: |
There was a problem hiding this comment.
If possible, I would prefer to avoid accessing private attributes.
Can you try instead to test if len(results) >= N: break?
There was a problem hiding this comment.
IMO, test might be something like below:
def test_set_and_clear(self):
# gh-57711: check that wait() returns true even when the event is
# cleared before the waiting thread is woken up.
event = self.eventtype()
N = 5
ready = []
results = []
def f():
ready.append(True)
results.append(event.wait(support.LONG_TIMEOUT))
with Bunch(f, N):
# Threads blocked on event.wait()
for _ in support.sleeping_retry(support.SHORT_TIMEOUT):
if len(ready) >= N:
break
# Threads unblocked
event.set()
for _ in support.sleeping_retry(support.SHORT_TIMEOUT):
if len(results) >= N:
break
event.clear()
self.assertEqual(results, [True] * N)There was a problem hiding this comment.
with Bunch(...): already waits until all started threads complete. Is it really needed to wait until len(results) >= N before calling event.clear()?
The test description says:
check that wait() returns true even when the event is cleared before the waiting thread is woken up.
Waiting for theads between set() and clear() seems to go against the test description.
|
@vstinner I suggest opening a PR to replace all |
4 participants
Instead of sleeping for 50 ms, wait until all five threads are registered as waiters on the event's condition before calling
set()andclear().Condition.wait()appends the waiter to_waiterswhile holding the lock, andnotify_all()wakes every waiter in that list, soset()then wakes all of them.With the reproducer from the issue, the test failed in 0 of 40 runs, against 9 of 40 before. The test still catches gh-57711 about as often as before: with
Event.wait()changed back to return the flag after waking, it failed in 8 of 20 runs, against 7 of 20 without this change.The other callers of
wait_threads_blocked()are not affected, because a thread that arrives late still finds the lock released, the semaphore available or the event set.This PR was prepared with the help of an AI assistant (Claude Code) and reviewed by me.