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 :-/

glibc v2.30 onwards provides sem_clockwait which can wait on either CLOCK_MONOTONIC or CLOCK_REALTIME. I failed to notice that https://sourceware.org/bugzilla/show_bug.cgi?id=14717 existed until today. :(

New changeset 09796f2f142fdb1214f34a3ca917959ecb32a88b by Victor Stinner in branch 'main':
bpo-41710: Add _PyTime_AsTimespec_clamp() (GH-28629)
https://github.com/python/cpython/commit/09796f2f142fdb1214f34a3ca917959ecb32a88b

New changeset d62d925823b005c33b432e527562b573a3a89635 by Victor Stinner in branch 'main':
bpo-41710: Add pytime_add() and pytime_mul() (GH-28642)
https://github.com/python/cpython/commit/d62d925823b005c33b432e527562b573a3a89635

New changeset 0231b6da45b610d33ee4e99bf190e31488d6ab26 by Victor Stinner in branch 'main':
bpo-41710: Fix building pytime.c on Windows (GH-28644)
https://github.com/python/cpython/commit/0231b6da45b610d33ee4e99bf190e31488d6ab26

New changeset 37b8294d6295ca12553fd7c98778be71d24f4b24 by Victor Stinner in branch 'main':
bpo-41710: PyThread_acquire_lock_timed() clamps the timout (GH-28643)
https://github.com/python/cpython/commit/37b8294d6295ca12553fd7c98778be71d24f4b24

New changeset b34dd58fee707b8044beaf878962a6fa12b304dc by Victor Stinner in branch 'main':
bpo-41710: Document _PyTime_t API in pytime.h (GH-28647)
https://github.com/python/cpython/commit/b34dd58fee707b8044beaf878962a6fa12b304dc

On Unix, PyCOND_TIMEDWAIT() is implemented with pthread_cond_timedwait(). If pthread_condattr_setclock() is available, it uses CLOCK_MONOTONIC. Otherwise, it uses CLOCK_REALTIME.

The glibc 2.30 adds pthread_cond_clockwait() which could be used to use CLOCK_MONOTONIC. But if pthread_cond_clockwait() is available (glibc 2.30 or newer), it expects that pthread_condattr_setclock() is also available. So I'm not sure that it's worth it to change PyCOND_TIMEDWAIT().

See the _PyThread_cond_after() function which computes an absolute timestamp (timespec) from a relative timeout in microseconds.

vstinner wrote:
> The glibc 2.30 adds pthread_cond_clockwait() which could be used to use
> CLOCK_MONOTONIC. But if pthread_cond_clockwait() is available (glibc 
> 2.30 or newer), it expects that pthread_condattr_setclock() is also 
> available. So I'm not sure that it's worth it to change 
> PyCOND_TIMEDWAIT().

That's correct. The only time that pthread_cond_clockwait is essential is if you don't know which clock you're going to need to use for the wait at the time of condition variable creation. (This is true for a generic condition variable wrapper that can be passed absolute timeouts using different clocks like the C++ std::condition_variable.)

However, sem_clockwait is the only way to wait on a semaphore using CLOCK_MONOTONIC, so it is worth using that rather than sem_timedwait if it's available. Similarly for pthread_mutex_clocklock.

New changeset 1ee0f94d16f150356a4b9b0a39d44ba1d2d5b9fc by Victor Stinner in branch 'main':
bpo-41710: PyThread_acquire_lock_timed() uses sem_clockwait() (GH-28662)
https://github.com/python/cpython/commit/1ee0f94d16f150356a4b9b0a39d44ba1d2d5b9fc

With sem_clockwait(CLOCK_MONOTONIC) on Fedora 34 (glibc-2.33-20.fc34.x86_64, Linux kernel 5.13.19-200.fc34.x86_64), time_test.py now works as expected:

$ sudo ./python time_test.py
Took 2.000 s
Took 2.000 s
Took 2.000 s
Took 2.000 s
Took 2.000 s
Took 2.000 s
(...)

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

Fixed bpo-12822 modified threading.Condition.wait(timeout) to use a monotonic clock: use pthread_condattr_setclock(CLOCK_MONOTONIC). bpo-23428, bpo-31267 and bpo-35747 are duplicates of bpo-12822.

This issue is about threading.Lock.acquire(timeout) which has a different implementation.

New changeset 98d282700221234157159df4af76423d89490ad9 by Victor Stinner in branch 'main':
bpo-41710: Fix PY_TIMEOUT_MAX on Windows (GH-28673)
https://github.com/python/cpython/commit/98d282700221234157159df4af76423d89490ad9

New changeset 54957f16a63ecb6b15f77b01fa7c55ada892604a by Victor Stinner in branch 'main':
bpo-41710: gc_collect_main() uses _PyTime_GetPerfCounter() (GH-28676)
https://github.com/python/cpython/commit/54957f16a63ecb6b15f77b01fa7c55ada892604a

New changeset 833fdf126c8fe77fd17e8a8ffbc5c571b3bf64bd by Victor Stinner in branch 'main':
bpo-41710: Add private _PyDeadline_Get() function (GH-28674)
https://github.com/python/cpython/commit/833fdf126c8fe77fd17e8a8ffbc5c571b3bf64bd

New changeset 6df8c327532627d6a99991993c52e8e4a9b34968 by Victor Stinner in branch '3.10':
bpo-41710: PyThread_acquire_lock_timed() uses sem_clockwait() (GH-28671)
https://github.com/python/cpython/commit/6df8c327532627d6a99991993c52e8e4a9b34968

New changeset 0e1aeab5d7de3f328876aea8ccabbc6db146a883 by Miss Islington (bot) in branch '3.9':
bpo-41710: PyThread_acquire_lock_timed() uses sem_clockwait() (GH-28671) (GH-28683)
https://github.com/python/cpython/commit/0e1aeab5d7de3f328876aea8ccabbc6db146a883

Jonas Norling: Thanks for the bug report! It's now fixed in 3.9, 3.10 and main branches.

New changeset 03bbc6066ff40c62edd57612be9150dcf1b123c8 by Victor Stinner in branch 'main':
bpo-41710: Fix What's New Entry credit (GH-28962)
https://github.com/python/cpython/commit/03bbc6066ff40c62edd57612be9150dcf1b123c8

bpo-33632 "undefined behaviour: signed integer overflow in threadmodule.c" has been fixed by this change:

New changeset 833fdf126c8fe77fd17e8a8ffbc5c571b3bf64bd by Victor Stinner in branch 'main':
bpo-41710: Add private _PyDeadline_Get() function (GH-28674)
https://github.com/python/cpython/commit/833fdf126c8fe77fd17e8a8ffbc5c571b3bf64bd