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 Thu, 11 May 2023 at 13:19, Mike Crowe
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, ...
> >>
> >> > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> >> > > i
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
> > > > > if (__s.count(
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 an absolute time if
> > > FUTEX_WAIT_B
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 2020 at 17:25:22 +, Jonathan
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
> > benefits:
> >
> > 1.
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
> > > +++ b/libstdc++-v3/include/bits/atomi
On Friday 11 September 2020 at 19:59:36 +0100, Jonathan Wakely wrote:
> commit 53ad6b1979f4bd7121e977c4a44151b14d8a0147
> Author: Jonathan Wakely
> Date: Fri Sep 11 19:59:11 2020
>
> libstdc++: Fix chrono::__detail::ceil to work with C++11
>
> In C++11 constexpr functions can only
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++-v3/include/bits/atomic_futex.h
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 and improve th
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
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 and improve the fix for PR68519 in
std::condition_variable.
v1 of this series wa
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
22 matches
Mail list logo
