GeezerVison is showing github.com — threading.Lock.acquire(timeout) should use sem_clockwait(CLOCK_MONOTONIC) · Issue #85876 · python/cpython
threading.Lock.acquire(timeout) should use sem_clockwait(CLOCK_MONOTONIC) #85876Labels 3.10 (EOL)end of lifeend of life3.11only security fixesonly security fixes3.9 (EOL)end of lifeend of lifeinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2021-10-01.16:52:29.583>
created_at = <Date 2020-09-04.08:34:54.835>
labels = ['interpreter-core', 'type-bug', '3.9', '3.10', '3.11']
title = 'threading.Lock.acquire(timeout) should use sem_clockwait(CLOCK_MONOTONIC)'
updated_at = <Date 2021-12-06.13:27:11.081>
user = 'https://bugs.python.org/wocket' bugs.python.org fields:
activity = <Date 2021-12-06.13:27:11.081>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2021-10-01.16:52:29.583>
closer = 'vstinner'
components = ['Interpreter Core']
creation = <Date 2020-09-04.08:34:54.835>
creator = 'wocket'
dependencies = []
files = ['49440']
hgrepos = []
issue_num = 41710
keywords = ['patch']
message_count = 22.0
messages = ['376338', '376340', '376394', '399405', '402925', '402926', '402931', '402939', '402942', '402987', '402995', '402997', '403001', '403003', '403009', '403011', '403012', '403021', '403022', '403023', '403962', '407802']
nosy_count = 5.0
nosy_names = ['vstinner', 'methane', 'miss-islington', 'wocket', 'mikecrowe']
pr_nums = ['28629', '28642', '28643', '28644', '28647', '28662', '28671', '28672', '28673', '28674', '28676', '28683', '28962']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue41710'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11'] Activitywocket commented on Sep 4, 2020 MannequinAuthor More actions 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). vstinner commented on Sep 4, 2020 bpo-23428 modified the pthread implementation of conditional variable to use pthread_condattr_setclock(&ca, CLOCK_MONOTONIC) is available: commit 001fee1. 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:
wocket commented on Sep 4, 2020 MannequinAuthor More actions 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 :-/ mikecrowe commented on Aug 11, 2021 changed the title [-]Timeout is affected by jumps in system time[/-] [+]acquire(timeout) of threading.Lock and threading.Condition is affected by jumps in system time: Python should use sem_clockwait(CLOCK_MONOTONIC)[/+] on Sep 13, 2021changed the title [-]Timeout is affected by jumps in system time[/-] [+]acquire(timeout) of threading.Lock and threading.Condition is affected by jumps in system time: Python should use sem_clockwait(CLOCK_MONOTONIC)[/+] on Sep 13, 2021vstinner commented on Sep 30, 2021 vstinner commented on Sep 30, 2021 vstinner commented on Sep 30, 2021 vstinner commented on Oct 1, 2021
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. vstinner commented on Oct 1, 2021 vstinner commented on Oct 1, 2021 vstinner commented on Oct 1, 2021 vstinner commented on Oct 1, 2021 vstinner commented on Oct 1, 2021 vstinner commented on Oct 1, 2021 Jonas Norling: Thanks for the bug report! It's now fixed in 3.9, 3.10 and main branches. vstinner commented on Oct 14, 2021 vstinner commented on Dec 6, 2021 bpo-33632 "undefined behaviour: signed integer overflow in threadmodule.c" has been fixed by this change:
New changeset 833fdf1 by Victor Stinner in branch 'main':
bpo-41710: Add private _PyDeadline_Get() function (GH-28674)
833fdf1
MetadataMetadata3.10 (EOL)end of lifeend of life3.11only security fixesonly security fixes3.9 (EOL)end of lifeend of lifeinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DevelopmentNo branches or pull requestsIssue actions
|