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
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
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, i
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
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 for a
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
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
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
> >
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 way
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
&
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.
>
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++-
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
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 th
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 newly-a
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
a
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 __atomic_futex_unsigned::_M_load_and_text_until_imp
30_threads/async/async.cc (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.
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 calls
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,
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.
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 conv
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 __atomic_futex_unsigned::_M_load_and_text_until_imp
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 th
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 conv
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.
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
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,
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:
(__atomic_fut
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 calls
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 h
* 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
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
timed_mutex::wait
* 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 d
* 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 a/libstdc++-
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.
* testsuite/30_
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:
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 repo
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,
shared_timed_mutex::try_lock_fo
* 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 changed,
1] https://gcc.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: A
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 from
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.
* testsuite/30_
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:
* 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 changed,
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 from
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 repo
* 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
* 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 a/libstdc++-
* 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 d
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
timed_mutex::wait
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 h
and with values 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
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,
shared_timed_mutex::try_lock_fo
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
> &
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
/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 to
::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
++-v3/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.
+
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
---
libstdc++-v3/inc
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 +-
libstdc+
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 sa
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 --gi
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 the
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 __atomic_futex_unsigned::_M_load_and_text_until_impl
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 calls
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,
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
conver
her I'm supposed 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_clo
bstdc++-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
++-v3/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 agains
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
bstdc++-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
++-v3/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
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:
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
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
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:
&g
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 the
://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
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 --gi
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
conver
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,
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 __atomic_futex_unsigned::_M_load_and_text_until_impl
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,
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 __atomic_futex_unsigned::_M_load_and_tex
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
conver
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 the
;t believe 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
E
ibc patch. See
https://gitlab.com/mikecrowe/glibc-monotonic .)
Signed-off-by: Mike Crowe
---
libstdc++-v3/acinclude.m4 | 31
libstdc++-v3/config.h.in | 3 +
libstdc++-v3/configure | 83
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.
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
> &g
hen
std::chrono::system_clock is deemed to be the "best" clock available
which means that the previous suboptimal behaviour remains.
Signed-off-by: Mike Crowe
---
libstdc++-v3/include/std/condition_variable| 56 ++
.../30_threads/condition_variable/members/2.
93 matches
Mail list logo