The timeout for threading.Lock, threading.Condition, etc, is not using a monotonic clock — it is affected if the system time (realtime clock) is set.

The attached program can be used to show the problem. It is expected to print "Took 2.000 s" repeatedly, but if run with permissions to set the system time, it prints:
$ sudo ./time_test.py
Took 2.400 s
Took 1.657 s
Took 2.044 s
Took 2.401 s
...

(the 1.6 s time can be explained by NTP correcting the clock)

There are already a number of closed bugs for this and related issues: bpo 23428, bpo 31267, bpo 35747.

This happens in Python 3.7.7 (ARM32, Yocto Warrior), Python 3.8.2 (AMD64, Ubuntu Linux 20.04) and Python v3.9.0rc1 (AMD64, Ubuntu Linux 20.04).

bpo-23428 modified the pthread implementation of conditional variable to use pthread_condattr_setclock(&ca, CLOCK_MONOTONIC) is available: commit 001fee14e0f2ba5f41fb733adc69d5965925a094. The change should be part of Python 3.8.

What is your sys.thread_info value? Example on Fedora 32 with Python 3.8.5:

>>> sys.thread_info
sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.31')

Sadly, the semaphore implementation doesn't use monotonic clock. See glibc issues:

* https://sourceware.org/bugzilla/show_bug.cgi?id=14717
* https://bugzilla.kernel.org/show_bug.cgi?id=112521

sys.thread_info = sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.31') on my system. Looking at the source I think the semaphore implementation will be used on all modern Linux systems.

In my tests it works as expected on a Macintosh (3.8.5 with lock='mutex+cond') and also if I force a Linux build to use the mutex+cond implementation by defining HAVE_BROKEN_POSIX_SEMAPHORES.

Doesn't look like those glibc and Linux bug reports will get any attention anytime soon. I will find a workaround instead :-/