test_multiprocessing_forkserver.test_processes.WithProcessesTestLock.test_repr_rlock is flaky

[mpage]

Bug report

Bug description:

The implementation of test_multiprocessing_forkserver.test_processes.WithProcessesTestLock.test_repr_rlock is racy; this leads to test failures on unrelated PRs:

• Example 1
• Example 2

The linked failures are a result of the raciness in the test:

cpython/Lib/test/_test_multiprocessing.py

Lines 1525 to 1530 in 30efede

	t = threading.Thread(target=self._acquire_release,
	args=(lock, 0.2),
	name=f'T1')
	t.start()
	time.sleep(0.1)
	self.assertEqual('<RLock(SomeOtherThread, nonzero)>', repr(lock))

and the function, _acquire_release, which runs in the thread:

cpython/Lib/test/_test_multiprocessing.py

Lines 1489 to 1497 in 30efede

	@staticmethod
	def _acquire_release(lock, timeout, l=None, n=1):
	for _ in range(n):
	lock.acquire()
	if l is not None:
	l.append(repr(lock))
	time.sleep(timeout)
	for _ in range(n):
	lock.release()

The tests will fail if _acquire_release runs to completion or doesn't acquire the lock before the test checks the repr.

We should rewrite test_repr_rlock so that it does not use time.sleep() as a mechanism for ordering events between different processes/threads.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux