public inbox for glibc-cvs@sourceware.org help / color / mirror / Atom feed
From: Adhemerval Zanella <azanella@sourceware.org> To: glibc-cvs@sourceware.org Subject: [glibc/azanella/master-posix_clock] nptl: Remove futex_supports_exact_relative_timeouts Date: Tue, 02 Jul 2019 17:27:00 -0000 [thread overview] Message-ID: <20190702172708.43539.qmail@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a53662bcb25094bfb79507585af8972f3b6d789f commit a53662bcb25094bfb79507585af8972f3b6d789f Author: Mike Crowe <mac@mcrowe.com> Date: Mon Jun 24 20:18:00 2019 +0000 nptl: Remove futex_supports_exact_relative_timeouts The only implementation of futex_supports_exact_relative_timeouts always returns true. Let's remove it and all its callers. * nptl/pthread_cond_wait.c: (__pthread_cond_clockwait): Remove code that is only useful if futex_supports_exact_relative_timeouts () returns false. * nptl/pthread_condattr_setclock.c: (pthread_condattr_setclock): Likewise. * sysdeps/nptl/futex-internal.h: Remove comment about relative timeouts potentially being imprecise since it's no longer true. Remove declaration of futex_supports_exact_relative_timeouts. * sysdeps/unix/sysv/linux/futex-internal.h: Remove implementation of futex_supports_exact_relative_timeouts. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Diff: --- ChangeLog | 11 +++++++++++ nptl/pthread_cond_wait.c | 5 ----- nptl/pthread_condattr_setclock.c | 5 ----- sysdeps/nptl/futex-internal.h | 9 +-------- sysdeps/unix/sysv/linux/futex-internal.h | 8 -------- 5 files changed, 12 insertions(+), 26 deletions(-) diff --git a/ChangeLog b/ChangeLog index f2cb99f..ab8bdd2 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,16 @@ 2019-07-02 Mike Crowe <mac@mcrowe.com> + * nptl/pthread_cond_wait.c: (__pthread_cond_clockwait): Remove code + that is only useful if futex_supports_exact_relative_timeouts () + returns false. + * nptl/pthread_condattr_setclock.c: (pthread_condattr_setclock): + Likewise. + * sysdeps/nptl/futex-internal.h: Remove comment about relative + timeouts potentially being imprecise since it's no longer true. + Remove declaration of futex_supports_exact_relative_timeouts. + * sysdeps/unix/sysv/linux/futex-internal.h: Remove implementation + of futex_supports_exact_relative_timeouts. + * NEWS: Mention recently-added pthread_cond_clockwait, pthread_rwlock_clockrdlock, pthread_rwlock_clockwrlock and sem_clockwait functions. diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c index 68ec754..450bf66b 100644 --- a/nptl/pthread_cond_wait.c +++ b/nptl/pthread_cond_wait.c @@ -674,11 +674,6 @@ __pthread_cond_clockwait (pthread_cond_t *cond, pthread_mutex_t *mutex, if (!futex_abstimed_supported_clockid (clockid)) return EINVAL; - /* If we do not support waiting using CLOCK_MONOTONIC, return an error. */ - if (clockid == CLOCK_MONOTONIC - && !futex_supports_exact_relative_timeouts ()) - return EINVAL; - return __pthread_cond_wait_common (cond, mutex, clockid, abstime); } weak_alias (__pthread_cond_clockwait, pthread_cond_clockwait); diff --git a/nptl/pthread_condattr_setclock.c b/nptl/pthread_condattr_setclock.c index 641a041..ac91923 100644 --- a/nptl/pthread_condattr_setclock.c +++ b/nptl/pthread_condattr_setclock.c @@ -33,11 +33,6 @@ pthread_condattr_setclock (pthread_condattr_t *attr, clockid_t clock_id) in the pthread_cond_t structure needs to be adjusted. */ return EINVAL; - /* If we do not support waiting using CLOCK_MONOTONIC, return an error. */ - if (clock_id == CLOCK_MONOTONIC - && !futex_supports_exact_relative_timeouts()) - return ENOTSUP; - /* Make sure the value fits in the bits we reserved. */ assert (clock_id < (1 << COND_CLOCK_BITS)); diff --git a/sysdeps/nptl/futex-internal.h b/sysdeps/nptl/futex-internal.h index f29d6d4..dff2317 100644 --- a/sysdeps/nptl/futex-internal.h +++ b/sysdeps/nptl/futex-internal.h @@ -51,8 +51,7 @@ Both absolute and relative timeouts can be used. An absolute timeout expires when the given specific point in time on the specified clock passes, or when it already has passed. A relative timeout expires when - the given duration of time on the CLOCK_MONOTONIC clock passes. Relative - timeouts may be imprecise (see futex_supports_exact_relative_timeouts). + the given duration of time on the CLOCK_MONOTONIC clock passes. Due to POSIX requirements on when synchronization data structures such as mutexes or semaphores can be destroyed and due to the futex design @@ -81,12 +80,6 @@ static __always_inline int futex_supports_pshared (int pshared); -/* Returns true if relative timeouts are robust to concurrent changes to the - system clock. If this returns false, relative timeouts can still be used - but might be effectively longer or shorter than requested. */ -static __always_inline bool -futex_supports_exact_relative_timeouts (void); - /* Atomically wrt other futex operations on the same futex, this blocks iff the value *FUTEX_WORD matches the expected value. This is semantically equivalent to: diff --git a/sysdeps/unix/sysv/linux/futex-internal.h b/sysdeps/unix/sysv/linux/futex-internal.h index 299d248..980b798 100644 --- a/sysdeps/unix/sysv/linux/futex-internal.h +++ b/sysdeps/unix/sysv/linux/futex-internal.h @@ -46,14 +46,6 @@ futex_supports_pshared (int pshared) return EINVAL; } -/* The Linux kernel supports relative timeouts measured against the - CLOCK_MONOTONIC clock. */ -static __always_inline bool -futex_supports_exact_relative_timeouts (void) -{ - return true; -} - /* See sysdeps/nptl/futex-internal.h for details. */ static __always_inline int futex_wait (unsigned int *futex_word, unsigned int expected, int private)
next reply other threads:[~2019-07-02 17:27 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-02 17:27 Adhemerval Zanella [this message] -- strict thread matches above, loose matches on Subject: below -- 2019-06-26 18:38 Adhemerval Zanella 2019-06-25 22:10 Adhemerval Zanella
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190702172708.43539.qmail@sourceware.org \ --to=azanella@sourceware.org \ --cc=glibc-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).