classification
Title: NewGIL should use CLOCK_MONOTONIC if possible.
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: inada.naoki, lemburg, neologix, pitrou, vstinner
Priority: normal Keywords: patch

Created on 2011-08-23 07:43 by inada.naoki, last changed 2019-02-20 10:36 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
use_monotonic_clock.patch inada.naoki, 2011-08-23 07:43 review
Pull Requests
URL Status Linked Edit
PR 11723 merged inada.naoki, 2019-02-01 16:43
PR 11723 merged inada.naoki, 2019-02-01 16:43
Messages (13)
msg142789 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2011-08-23 07:43
Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL
because settimeofday() may break the pthread_cond_timedwait().

Attached patch uses CLOCK_MONOTONIC and clock_gettime. But I don't know
how to write appropriate configure script.
"-lrt" is also needed to use clock_gettime() but I don't know how to add
it to LIBS.
msg142791 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-08-23 07:59
See also #10278.
msg142856 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-08-23 18:54
> Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL
> because settimeofday() may break the pthread_cond_timedwait().

Indeed.
A couple remarks:
- regular locks and conditions variables exposed by the threading module suffer from the same problem
- POSIX semaphores are also affected, but you can't select an alternative clock source
- actually, CLOCK_MONOTONIC is affected by NTP adjustements: while it's guaranteed not to go backward, its rate can be affected

Did you really encounter this problem, or is this just a theoretical concern?
msg142858 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-08-23 19:03
The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time.
msg142859 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2011-08-23 19:15
Antoine Pitrou wrote:
> 
> The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time.

I think we need both: a check at build time to avoid
compiler errors and a check at runtime whether the deployment
platform supports the clock, plus a fallback solution in case
it is not available.
msg148525 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-11-28 23:46
> The patch is ok on the principle, but we do need a check
> that CLOCK_MONOTONIC is supported at build time.

timemodule.c is now using "#ifdef CLOCK_MONOTONIC".
msg148528 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-28 23:52
Marc-Andre is right, a runtime check is probably also needed.
(for example with mismatching kernel/libc)
msg148529 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-11-28 23:54
pthread_condattr_setclock() result should be checked.

"The pthread_condattr_setclock() function may fail if:

EINVAL The value specified by clock_id does not refer to a known clock, or is a CPU-time clock."
msg155837 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-03-15 01:22
See also #14222. Python 3.3 has a new time.steady() function.
msg334621 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2019-01-31 11:19
ref: https://bugs.chromium.org/p/webrtc/issues/detail?id=9269
macOS and iOS don't support pthread_condattr_setclock yet.
msg334623 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-01-31 11:33
See also bpo-23428: "Use the monotonic clock for thread conditions on POSIX platforms".
msg336032 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2019-02-20 01:00
New changeset 001fee14e0f2ba5f41fb733adc69d5965925a094 by Inada Naoki in branch 'master':
bpo-12822: use monotonic clock for condvar if possible (GH-11723)
https://github.com/python/cpython/commit/001fee14e0f2ba5f41fb733adc69d5965925a094
msg336061 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-02-20 10:36
Thanks INADA-san for fixing this old issue!
History
Date User Action Args
2019-02-20 10:36:02vstinnersetmessages: + msg336061
2019-02-20 01:00:28inada.naokisetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2019-02-20 01:00:13inada.naokisetmessages: + msg336032
2019-02-01 16:43:27inada.naokisetstage: patch review
pull_requests: + pull_request11602
2019-02-01 16:43:16inada.naokisetstage: (no value)
pull_requests: + pull_request11601
2019-02-01 06:07:37anacrolixsetnosy: - anacrolix
2019-01-31 11:33:56vstinnersetmessages: + msg334623
2019-01-31 11:19:08inada.naokisetmessages: + msg334621
components: + Interpreter Core, - None
versions: + Python 3.8, - Python 3.2, Python 3.3
2012-03-15 01:22:35vstinnersetmessages: + msg155837
2011-11-28 23:54:44vstinnersetmessages: + msg148529
2011-11-28 23:52:36pitrousetmessages: + msg148528
2011-11-28 23:46:55vstinnersetmessages: + msg148525
2011-11-26 01:09:19anacrolixsetnosy: + anacrolix
2011-08-23 19:15:12lemburgsetnosy: + lemburg
messages: + msg142859
2011-08-23 19:03:42pitrousetnosy: + pitrou
messages: + msg142858
2011-08-23 18:54:28neologixsetnosy: + neologix
messages: + msg142856
2011-08-23 07:59:58vstinnersetmessages: + msg142791
2011-08-23 07:59:35vstinnersetnosy: + vstinner
2011-08-23 07:43:36inada.naokicreate