Re: [PATCH v2] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer

On Friday 12 May 2023 at 11:32:56 +0100, Jonathan Wakely wrote: > On Fri, 12 May 2023 at 11:30, Mike Crowe wrote: > > On Thursday 11 May 2023 at 21:52:22 +0100, Jonathan Wakely wrote: > > > On Thu, 11 May 2023 at 13:42, Jonathan Wakely > > wrote: > > > > On T

Re: [PATCH v2] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer

On Thursday 11 May 2023 at 21:52:22 +0100, Jonathan Wakely wrote: > On Thu, 11 May 2023 at 13:42, Jonathan Wakely wrote: > > > > > > > On Thu, 11 May 2023 at 13:19, Mike Crowe wrote: > > > >> However, ... > >> > >> > > dif

Re: [RFC] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer

On Wednesday 10 May 2023 at 12:31:12 +0100, Jonathan Wakely wrote: > On Wed, 10 May 2023 at 12:20, Jonathan Wakely via Libstdc++ < > libstd...@gcc.gnu.org> wrote: > > > This patch would avoid TSan false positives when using timed waiting > > functions on mutexes and condvars, but as noted below,

Re: [committed] libstdc++: Use custom timespec in system calls [PR 93421]

On Wednesday 18 November 2020 at 20:22:53 +, Jonathan Wakely wrote: > On 18/11/20 00:01 +, Jonathan Wakely wrote: > > On 14/11/20 14:23 +, Jonathan Wakely wrote: > > > On Sat, 14 Nov 2020, 13:30 Mike Crowe wrote: > > > > > @@ -195,7 +205,7 @@ namespace

Re: [PATCH v5 2/8] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

On Friday 13 November 2020 at 21:58:25 +, Mike Crowe via Libstdc++ wrote: > On Thursday 12 November 2020 at 23:07:47 +, Jonathan Wakely wrote: > > On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote: > > > The futex system call supports waiting fo

Re: [committed] libstdc++: Use custom timespec in system calls [PR 93421]

On Saturday 14 November 2020 at 00:17:59 +, Jonathan Wakely via Libstdc++ wrote: > On 32-bit targets where userspace has switched to 64-bit time_t, we > cannot pass struct timespec to SYS_futex or SYS_clock_gettime, because > the userspace definition of struct timespec will not match what the

Re: [committed] libstdc++: Optimise std::future::wait_for and fix futex polling

On Saturday 14 November 2020 at 00:17:22 +, Jonathan Wakely wrote: > On 13/11/20 22:45 +, Jonathan Wakely wrote: > > On 13/11/20 21:12 +, Jonathan Wakely wrote: > > > On 13/11/20 20:29 +, Mike Crowe via Libstdc++ wrote: > > > > On Friday 13 November 20

Re: [PATCH v5 2/8] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

On Thursday 12 November 2020 at 23:07:47 +, Jonathan Wakely wrote: > On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote: > > The futex system call supports waiting for an absolute time if > > FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two > >

Re: [committed] libstdc++: Optimise std::future::wait_for and fix futex polling

On Friday 13 November 2020 at 17:25:22 +, Jonathan Wakely wrote: > On 13/11/20 11:02 +, Jonathan Wakely wrote: > > On 12/11/20 23:49 +, Jonathan Wakely wrote: > > > To poll a std::future to see if it's ready you have to call one of the > > > timed waiting functions. The most obvious

Re: [PATCH v5 6/8] libstdc++ atomic_futex: Avoid rounding errors in std::future::wait_* [PR91486]

On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote: > > > diff --git a/libstdc++-v3/include/bits/atomic_futex.h > > > b/libstdc++-v3/include/bits/atomic_futex.h > > > index 5f95ade..aa137a7 100644 > > > --- a/libstdc++-v3/include/bits/atomic_futex.h &

libstdc++: Fix chrono::__detail::ceil to work with C++11 (was Re: [PATCH v5 6/8] libstdc++ atomic_futex: Avoid rounding errors in std::future::wait_* [PR91486])

as far as I can tell, has no tests. A patch is attached to add the equivalent of the existing chrono::ceil tests for chrono::__detail::ceil. The tests fail to compile if I run them without 53ad6b1979f4bd7121e977c4a44151b14d8a0147 as expected due to the previous non-C++11-compliant implementation. Mike. >

Re: [PATCH v5 5/8] libstdc++ futex: Loop when waiting against arbitrary clock

On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote: > > diff --git a/libstdc++-v3/include/bits/atomic_futex.h > > b/libstdc++-v3/include/bits/atomic_futex.h > > index 4375129..5f95ade 100644 > > --- a/libstdc++-v3/include/bits/atomic_futex.h > > +++ b/libstdc++-

Re: [PATCH v5 0/8] std::future::wait_* and std::condition_variable improvements

On Friday 29 May 2020 at 07:17:26 +0100, Mike Crowe wrote: > This series ensures that the std::future::wait_* functions use > std::chrono::steady_clock when required, introduces > std::chrono::__detail::ceil to make that easier to do, and then makes > use of that function to simplify

[PATCH v5 2/8] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

The futex system call supports waiting for an absolute time if FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two benefits: 1. The call to gettimeofday is not required in order to calculate a relative timeout. 2. If someone changes the system clock during the wait then

[PATCH v5 7/8] libstdc++ condition_variable: Avoid rounding errors on custom clocks

The fix for PR68519 in 83fd5e73b3c16296e0d7ba54f6c547e01c7eae7b only applied to condition_variable::wait_for. This problem can also apply to condition_variable::wait_until but only if the custom clock is using a more recent epoch so that a small enough delta can be calculated. let's use the

[PATCH v5 6/8] libstdc++ atomic_futex: Avoid rounding errors in std::future::wait_* [PR91486]

Convert the specified duration to the target clock's duration type before adding it to the current time in __atomic_futex_unsigned::_M_load_when_equal_for and _M_load_when_equal_until. This removes the risk of the timeout being rounded down to the current time resulting in there being no wait at

[PATCH v5 3/8] libstdc++ futex: Support waiting on std::chrono::steady_clock directly

The user-visible effect of this change is for std::future::wait_until to use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock type. This makes it immune to any changes made to the system clock CLOCK_REALTIME. Add an overload of

[PATCH v5 0/8] std::future::wait_* and std::condition_variable improvements

(test02): Test steady_clock with std::future::wait_until. (test03): Add new test templated on clock type waiting for future associated with async to resolve. (main): Call test03 to test both system_clock and steady_clock. Mike Crowe (8): libstdc

[PATCH v5 5/8] libstdc++ futex: Loop when waiting against arbitrary clock

If std::future::wait_until is passed a time point measured against a clock that is neither std::chrono::steady_clock nor std::chrono::system_clock then the generic implementation of __atomic_futex_unsigned::_M_load_when_equal_until is called which calculates the timeout based on __clock_t and

[PATCH v5 8/8] libstdc++: Extra async tests, not for merging

These tests show that changing the system clock has an effect on std::future::wait_until when using std::chrono::system_clock but not when using std::chrono::steady_clock. Unfortunately these tests have a number of downsides: 1. Nothing that is attempting to keep the clock set correctly (ntpd,

[PATCH v5 1/8] libstdc++: Improve async test

Add tests for waiting for the future using both std::chrono::steady_clock and std::chrono::system_clock in preparation for dealing with those clocks properly in futex.cc. * libstdc++-v3/testsuite/30_threads/async/async.cc (test02): Test steady_clock with std::future::wait_until.

[PATCH v5 4/8] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock

The user-visible effect of this change is that std::future::wait_for now uses std::chrono::steady_clock to determine the timeout. This makes it immune to changes made to the system clock. It also means that anyone using their own clock types with std::future::wait_until will have the timeout

[PATCH v4 3/7] libstdc++ futex: Support waiting on std::chrono::steady_clock directly

The user-visible effect of this change is for std::future::wait_until to use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock type. This makes it immune to any changes made to the system clock CLOCK_REALTIME. Add an overload of

[PATCH v4 2/7] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

The futex system call supports waiting for an absolute time if FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two benefits: 1. The call to gettimeofday is not required in order to calculate a relative timeout. 2. If someone changes the system clock during the wait then

[PATCH v4 4/7] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock

The user-visible effect of this change is that std::future::wait_for now uses std::chrono::steady_clock to determine the timeout. This makes it immune to changes made to the system clock. It also means that anyone using their own clock types with std::future::wait_until will have the timeout

[PATCH v4 1/7] libstdc++: Improve async test

Add tests for waiting for the future using both std::chrono::steady_clock and std::chrono::system_clock in preparation for dealing with those clocks properly in futex.cc. * libstdc++-v3/testsuite/30_threads/async/async.cc (test02): Test steady_clock with std::future::wait_until.

[PATCH v4 0/7] std::future::wait_* improvements

minor tweaks to tests and comments. Combined ChangeLog entry (generated from the separate messages in each commit): 2019-10-27 Mike Crowe * libstdc++-v3/testsuite/30_threads/async/async.cc (test02): Test steady_clock with std::future::wait_until. (test03): Add new test

[PATCH v4 7/7] libstdc++: Extra async tests, not for merging

These tests show that changing the system clock has an effect on std::future::wait_until when using std::chrono::system_clock but not when using std::chrono::steady_clock. Unfortunately these tests have a number of downsides: 1. Nothing that is attempting to keep the clock set correctly (ntpd,

[PATCH v4 6/7] libstdc++ atomic_futex: Avoid rounding errors in std::future::wait_for

Convert the specified duration to the target clock's duration type before adding it to the current time. This avoids the situation described in PR libstdc++/68519 when the specified duration type lacks sufficient precision. * libstdc++-v3/include/bits/atomic_futex.h:

[PATCH v4 5/7] libstdc++ futex: Loop when waiting against arbitrary clock

If std::future::wait_until is passed a time point measured against a clock that is neither std::chrono::steady_clock nor std::chrono::system_clock then the generic implementation of __atomic_futex_unsigned::_M_load_when_equal_until is called which calculates the timeout based on __clock_t and

[PATCH v2 07/11] PR libstdc++/91906 Fix timed_mutex::try_lock_until on arbitrary clock

A non-standard clock may tick more slowly than std::chrono::steady_clock. This means that we risk returning false early when the specified timeout may not have expired. This can be avoided by looping until the timeout time as reported by the non-standard clock has been reached. Unfortunately, we

[PATCH v2 04/11] libstdc++ testsuite: Also test unique_lock::try_lock_until with steady_clock

* testsuite/30_threads/unique_lock/locking/4.cc: Template test functions so they can be used to test both steady_clock and system_clock. --- libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc | 12 +-- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git

[PATCH v2 05/11] PR libstdc++/78237 Add full steady_clock support to timed_mutex

The pthread_mutex_clocklock function is available in glibc since the 2.30 release. If this function is available in the C library it can be used to fix PR libstdc++/78237 by supporting steady_clock properly with timed_mutex. This means that code using timed_mutex::try_lock_for or

[PATCH v2 03/11] libstdc++ testsuite: Also test timed_mutex with steady_clock

* testsuite/30_threads/timed_mutex/try_lock_until/57641.cc: Template test functions and use them to test both steady_clock and system_clock. --- libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/57641.cc | 18 +- 1 file changed, 13 insertions(+), 5

[PATCH v2 01/11] libstdc++ testsuite: Check return value from timed_mutex::try_lock_until

* testsuite/30_threads/unique_lock/locking/4.cc: Wrap call to timed_mutex::try_lock_until in VERIFY macro to check its return value. --- libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 02/11] libstdc++ testsuite: Add timed_mutex::try_lock_until test

I was unable to find an existing tests for timed_mutex::try_lock_until and recursive_timed_mutex::try_lock_until timing out. It would have been easier to add a single templated test, but since these classes are tested in separate directories I've created two separate tests. *

[PATCH v2 10/11] libstdc++ timed_mutex: Ensure that try_lock_for waits for long enough

The user-defined clock used with shared_mutex::try_lock_for and shared_mutex::try_lock_shared_for may have higher precision than __clock_t. We may need to round the duration up to ensure that the timeout is long enough. (See __timed_mutex_impl::_M_try_lock_for) * include/std/shared_mutex:

[PATCH v2 11/11] shared_mutex: Fix try_lock_until and try_lock_shared_until on arbitrary clock

This is the equivalent to PR libstdc++/91906, but for shared_mutex. A non-standard clock may tick more slowly than std::chrono::steady_clock. This means that we risk returning false early when the specified timeout may not have expired. This can be avoided by looping until the timeout time as

[PATCH v2 09/11] libstdc++ shared_mutex: Add full steady_clock support to shared_timed_mutex

The pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock functions were added to glibc in v2.30. They have also been added to Android Bionic. If these functions are available in the C library then they can be used to implement shared_timed_mutex::try_lock_until,

[PATCH v2 08/11] libstdc++ testsuite: Also test shared_timed_mutex with steady_clock

* testsuite/30_threads/shared_timed_mutex/try_lock/3.cc: Convert existing test to templated function so that it can be called with both system_clock and steady_clock. --- libstdc++-v3/testsuite/30_threads/shared_timed_mutex/try_lock/3.cc | 17 - 1 file

[PATCH v2 00/11] timed_mutex, shared_timed_mutex: Add full steady clock support

gnu.org/ml/libstdc++/2019-09/msg00106.html [2] https://gcc.gnu.org/ml/libstdc++/2019-10/msg00021.html Mike Crowe (11): libstdc++ testsuite: Check return value from timed_mutex::try_lock_until libstdc++ testsuite: Add timed_mutex::try_lock_until test libstdc++ testsuite: Also test t

[PATCH v2 06/11] libstdc++ testsuite: Move slow_clock to its own header

Move slow_clock test class into a header file so that it can be used by other tests in the future. * testsuite/util/slow_clock.h: New file. Move implementation of slow_clock test class. * testsuite/30_threads/condition_variable/members/2.cc: Include slow_clock

[PATCH 02/11] libstdc++ testsuite: Add timed_mutex::try_lock_until test

I was unable to find an existing tests for timed_mutex::try_lock_until and recursive_timed_mutex::try_lock_until timing out. It would have been easier to add a single templated test, but since these classes are tested in separate directories I've created two separate tests. *

[PATCH 10/11] libstdc++ timed_mutex: Ensure that try_lock_for waits for long enough

The user-defined clock used with shared_mutex::try_lock_for and shared_mutex::try_lock_shared_for may have higher precision than __clock_t. We may need to round the duration up to ensure that the timeout is long enough. (See __timed_mutex_impl::_M_try_lock_for) * include/std/shared_mutex:

[PATCH 08/11] libstdc++ testsuite: Also test shared_timed_mutex with steady_clock

* testsuite/30_threads/shared_timed_mutex/try_lock/3.cc: Convert existing test to templated function so that it can be called with both system_clock and steady_clock. --- libstdc++-v3/testsuite/30_threads/shared_timed_mutex/try_lock/3.cc | 17 - 1 file

[PATCH 06/11] libstdc++ testsuite: Move slow_clock to its own header

Move slow_clock test class into a header file so that it can be used by other tests in the future. * testsuite/util/slow_clock.h: New file. Move implementation of slow_clock test class. * testsuite/30_threads/condition_variable/members/2.cc: Include slow_clock

[PATCH 11/11] shared_mutex: Fix try_lock_until and try_lock_shared_until on arbitrary clock

This is the equivalent to PR libstdc++/91906, but for shared_mutex. A non-standard clock may tick more slowly than std::chrono::steady_clock. This means that we risk returning false early when the specified timeout may not have expired. This can be avoided by looping until the timeout time as

[PATCH 04/11] libstdc++ testsuite: Also test unique_lock::try_lock_until with steady_clock

* testsuite/30_threads/unique_lock/locking/4.cc: Template test functions so they can be used to test both steady_clock and system_clock. --- libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc | 12 +-- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git

[PATCH 01/11] libstdc++ testsuite: Check return value from timed_mutex::try_lock_until

* testsuite/30_threads/unique_lock/locking/4.cc: Wrap call to timed_mutex::try_lock_until in VERIFY macro to check its return value. --- libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 03/11] libstdc++ testsuite: Also test timed_mutex with steady_clock

* testsuite/30_threads/timed_mutex/try_lock_until/57641.cc: Template test functions and use them to test both steady_clock and system_clock. --- libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/57641.cc | 18 +- 1 file changed, 13 insertions(+), 5

[PATCH 05/11] PR libstdc++/78237 Add full steady_clock support to timed_mutex

The pthread_mutex_clocklock function is available in glibc since the 2.30 release. If this function is available in the C library it can be used to fix PR libstdc++/78237 by supporting steady_clock properly with timed_mutex. This means that code using timed_mutex::try_lock_for or

[PATCH 09/11] libstdc++ shared_mutex: Add full steady_clock support to shared_timed_mutex

The pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock functions were added to glibc in v2.30. They have also been added to Android Bionic. If these functions are available in the C library then they can be used to implement shared_timed_mutex::try_lock_until,

[PATCH 07/11] PR libstdc++/91906 Fix timed_mutex::try_lock_until on arbitrary clock

A non-standard clock may tick more slowly than std::chrono::steady_clock. This means that we risk returning false early when the specified timeout may not have expired. This can be avoided by looping until the timeout time as reported by the non-standard clock has been reached. Unfortunately, we

[PATCH 00/11] timed_mutex, shared_timed_mutex: Add full steady clock support

of tv_sec based on the system uptime when using steady_clock. This series also adds some extra tests and fixes some other minor problems with the existing implementation and tests. Mike Crowe (11): libstdc++ testsuite: Check return value from timed_mutex::try_lock_until libstdc++ test

Re: [PATCH 2/2] PR libstdc++/41861 Add full steady_clock support to condition_variable

On Wednesday 04 September 2019 at 14:39:35 +0100, Jonathan Wakely wrote: > On 15/07/19 17:47 +0100, Mike Crowe wrote: > > The pthread_cond_clockwait function was recently added[1] to glibc, and is > > due to be released in glibc 2.30. If this function is available in the C >

Re: [PATCH 0/2] PR libstdc++/41861 Add full steady_clock support to condition_variable

On Monday 15 July 2019 at 17:47:47 +0100, Mike Crowe wrote: > The pthread_cond_clockwait function was recently added[1] to glibc, > and is due to be released in glibc 2.30. If this function is available > in the C library it can be used it to fix > https://gcc.gnu.org/bugzilla/sho

[PATCH 1/2] Add user-defined clock to libstdc++ condition_variable tests

/ChangeLog @@ -1,3 +1,12 @@ +2019-07-15 Mike Crowe + + * testsuite/30_threads/condition_variable/members/2.cc (test01): + Parameterise so that test can be run against an arbitrary clock. + (main): Test using std::chrono::steady_clock and a user-defined + clock in addition

[PATCH 0/2] PR libstdc++/41861 Add full steady_clock support to condition_variable

::condition_variable. Mike Crowe (2): Add user-defined clock to libstdc++ condition_variable tests PR libstdc++/41861 Add full steady_clock support to condition_variable libstdc++-v3/ChangeLog| 34 +- libstdc++-v3

[PATCH 2/2] PR libstdc++/41861 Add full steady_clock support to condition_variable

/ChangeLog b/libstdc++-v3/ChangeLog index a52a704..597000b 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,5 +1,30 @@ 2019-07-15 Mike Crowe + * include/std/condition_variable: Add include of + to make _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT available. +

[PATCH] Use steady_clock to implement condition_variable::wait_for with predicate

In r263225 (d2e378182a12d68fe5caeffae681252662a2fe7b), I fixed condition_variable::wait_for to use std::chrono::steady_clock for the wait. Unfortunately, I failed to spot that the same fix is required for the wait_for variant that takes a predicate too. Reported-by: Tom Wood ---

[PATCH] atomic_futex: Avoid rounding errors in std::future::wait_for

Convert the specified duration to the target clock's duration type before adding it to the current time. This avoids the situation described in PR libstdc++/68519 when the specified duration type lacks sufficient precision. --- libstdc++-v3/include/bits/atomic_futex.h | 6 +-

Re: [PATCHv3 3/6] libstdc++ futex: Support waiting on std::chrono::steady_clock directly

On Wednesday 01 August 2018 at 20:38:33 +0100, Jonathan Wakely wrote: > On 01/08/18 14:19 +0100, Mike Crowe wrote: > > I believe that I've added this functionality in a way that it doesn't break > > ABI compatibility, but that has made it more verbose and less type safe

[PATCHv3 1/6] Improve libstdc++-v3 async test

Add tests for waiting for the future using both std::chrono::steady_clock and std::chrono::system_clock in preparation for dealing with those clocks properly in futex.cc. --- libstdc++-v3/testsuite/30_threads/async/async.cc | 33 1 file changed, 33 insertions(+) diff

[PATCHv3 2/6] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

The futex system call supports waiting for an absolute time if FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two benefits: 1. The call to gettimeofday is not required in order to calculate a relative timeout. 2. If someone changes the system clock during the wait then

[PATCHv3 3/6] libstdc++ futex: Support waiting on std::chrono::steady_clock directly

The user-visible effect of this change is for std::future::wait_until to use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock type. This makes it immune to any changes made to the system clock CLOCK_REALTIME. Add an overload of

[PATCHv3 5/6] libstdc++ futex: Loop when waiting against arbitrary clock

If std::future::wait_until is passed a time point measured against a clock that is neither std::chrono::steady_clock nor std::chrono::system_clock then the generic implementation of __atomic_futex_unsigned::_M_load_when_equal_until is called which calculates the timeout based on __clock_t and

[PATCHv3 6/6] Extra async tests, not for merging

These tests show that changing the system clock has an effect on std::future::wait_until when using std::chrono::system_clock but not when using std::chrono::steady_clock. Unfortunately these tests have a number of downsides: 1. Nothing that is attempting to keep the clock set correctly (ntpd,

[PATCHv3 4/6] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock

The user-visible effect of this change is that std::future::wait_for now uses std::chrono::steady_clock to determine the timeout. This makes it immune to changes made to the system clock. It also means that anyone using their own clock types with std::future::wait_until will have the timeout

[PATCHv3 0/6] std::future::wait_* improvements

osed to do that as part of the patches, or not. Mike Crowe (6): Improve libstdc++-v3 async test libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait libstdc++ futex: Support waiting on std::chrono::steady_clock directly libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock

[PATCH 2/2] condition_variable: Use steady_clock to implement wait_for

++-v3/include/std/condition_variable | 5 +++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 4657af7..432cb84 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,4 +1,7 @@ 2018-07-20 Mike Crowe

[PATCH 1/2] condition_variable: Report early wakeup of wait_until as no_timeout

/ChangeLog b/libstdc++-v3/ChangeLog index c9cd62a..4657af7 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,10 @@ +2018-07-20 Mike Crowe + * include/std/condition_variable (wait_until): Only report timeout + if we really have timed out when measured against

Re: [PATCH 1/2] condition_variable: Report early wakeup of wait_until as no_timeout

On Friday 20 July 2018 at 11:53:38 +0100, Jonathan Wakely wrote: > On 10/07/18 11:09 +0100, Mike Crowe wrote: > > As currently implemented, condition_variable always ultimately waits > > against std::chrono::system_clock. This clock can be changed in arbitrary > > ways by the

[PATCH 2/2] condition_variable: Use steady_clock to implement wait_for

++-v3/include/std/condition_variable | 5 +++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index ea7875ace9f..4500273ace7 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,4 +1,7 @@ 2018-07-09 Mike Crowe

[PATCH 1/2] condition_variable: Report early wakeup of wait_until as no_timeout

/include/std/condition_variable | 8 +++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index cceef0271ae..ea7875ace9f 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,8 @@ +2018-07-09 Mike Crowe

Re: [PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required

On Sunday 14 January 2018 at 20:44:10 +, Mike Crowe wrote: > On Sunday 14 January 2018 at 16:08:09 +0000, Mike Crowe wrote: > > Hi Torvald, > > > > Thanks for reviewing this change. > > > > On Saturday 13 January 2018 at 16:29:57 +0100, Torvald Riegel wrote:

Re: [PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required

On Sunday 14 January 2018 at 16:08:09 +, Mike Crowe wrote: > Hi Torvald, > > Thanks for reviewing this change. > > On Saturday 13 January 2018 at 16:29:57 +0100, Torvald Riegel wrote: > > On Sun, 2018-01-07 at 20:55 +, Mike Crowe wrote: > > > This is a fir

Re: [PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required

Hi Torvald, Thanks for reviewing this change. On Saturday 13 January 2018 at 16:29:57 +0100, Torvald Riegel wrote: > On Sun, 2018-01-07 at 20:55 +0000, Mike Crowe wrote: > > This is a first attempt to make std::future::wait_until and > > std::future::wait_for make correct use of

Re: [PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

On Tuesday 09 January 2018 at 13:50:54 +, Jonathan Wakely wrote: > On 07/01/18 20:55 +0000, Mike Crowe wrote: > > The futex system call supports waiting for an absolute time if > > FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two > > benefits:

[PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

The futex system call supports waiting for an absolute time if FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two benefits: 1. The call to gettimeofday is not required in order to calculate a relative timeout. 2. If someone changes the system clock during the wait then

[PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required

://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 for std::condition_variable, but with the benefit that this time the bug can be fixed entirely within libstdc++. (I've omitted the ChangeLog entries for now, since I don't believe that this is ready to be accepted in its current form.) Mike Crowe (5): Improve

[PATCH 1/5] Improve libstdc++-v3 async test

Add tests for waiting for the future using both std::chrono::steady_clock and std::chrono::system_clock in preparation for dealing with those clocks properly in futex.cc. --- libstdc++-v3/testsuite/30_threads/async/async.cc | 36 1 file changed, 36 insertions(+) diff

[PATCH 4/5] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock

The user-visible effect of this change is that std::future::wait_for now uses std::chrono::steady_clock to determine the timeout. This makes it immune to changes made to the system clock. It also means that anyone using their own clock types with std::future::wait_until will have the timeout

[PATCH 5/5] Extra async tests, not for merging

These tests show that changing the system clock has an effect on std::future::wait_until when using std::chrono::system_clock but not when using std::chrono::steady_clock. Unfortunately these tests have a number of downsides: 1. Nothing that is attempting to keep the clock set correctly (ntpd,

[PATCH 3/5] libstdc++ futex: Support waiting on std::chrono::steady_clock directly

The user-visible effect of this change is for std::future::wait_until to use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock type. This makes it immune to any changes made to the system clock CLOCK_REALTIME. Add an overload of

[RFC PATCH 4/4] Extra async tests, not for merging

These tests show that changing the system clock has an effect on std::future::wait_until when using std::chrono::system_clock but not when using std::chrono::steady_clock. Unfortunately these tests have a number of downsides: 1. Nothing that is attempting to keep the clock set correctly (ntpd,

[RFC PATCH 2/4] libstdc++ futex: Support waiting on std::chrono::steady_clock directly

The user-visible effect of this change is for std::future::wait_until to use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock::time_point type. This makes it immune to any changes made to the system clock CLOCK_REALTIME. Add an overload of

[RFC PATCH 3/4] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock

The user-visible effect of this change is that std::future::wait_for now uses std::chrono::steady_clock to determine the timeout. This makes it immune to changes made to the system clock. It also means that anyone using their own clock types with std::future::wait_until will have the timeout

[RFC PATCH 1/4] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

The futex system call supports waiting for an absolute time if FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two benefits: 1. The call to gettimeofday is not required in order to calculate a relative timeout. 2. If someone changes the system clock during the wait then

[RFC PATCH 0/4] Make std::future::wait_* use std::chrono::steady_clock when required

that this is ready to be accepted in its current form.) Mike. Mike Crowe (4): libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait libstdc++ futex: Support waiting on std::chrono::steady_clock directly libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock Extra async

[RFCv2] Add steady_clock support to condition_variable

://gitlab.com/mikecrowe/glibc-monotonic .) Signed-off-by: Mike Crowe m...@mcrowe.com --- libstdc++-v3/acinclude.m4 | 31 libstdc++-v3/config.h.in | 3 + libstdc++-v3/configure | 83 ++ libstdc++-v3

[RFC 2/2] Add steady_clock support to condition_variable

::system_clock is deemed to be the best clock available which means that the previous suboptimal behaviour remains. Signed-off-by: Mike Crowe m...@mcrowe.com --- libstdc++-v3/include/std/condition_variable| 56 ++ .../30_threads/condition_variable/members/2.cc | 8

Re: [RFC 1/2] gthread: Add __gthread_cond_timedwaitonclock

On Monday 06 July 2015 at 14:51:42 +0100, Jonathan Wakely wrote: On 06/07/15 13:55 +0100, Mike Crowe wrote: diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h index fb59816..0e01866 100644 --- a/libgcc/gthr-posix.h +++ b/libgcc/gthr-posix.h @@ -33,6 +33,7 @@ see the files COPYING3

Re: [RFC 2/2] Add steady_clock support to condition_variable

On Monday 06 July 2015 at 14:54:06 +0100, Jonathan Wakely wrote: Do you have a copyright assignment in place for GCC contributions? Not yet. From my reading of https://gcc.gnu.org/contribute.html I should probably ask you for the forms. :-) Mike.