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

[Jonathan Wakely]

On 01/08/18 20:49 +0100, Jonathan Wakely wrote:
>On 01/08/18 14:19 +0100, Mike Crowe wrote:
>>v2 of this series was originally posted back in January (see
>>https://gcc.gnu.org/ml/libstdc++/2018-01/msg00035.html )
>>
>>Apart from minor log message tweaks, the changes since that version are:
>>
>>* [1/6] Improve libstdc++-v3 async test
>>
>> Speed up the tests at the risk of more sporadic failures on loaded
>> machines.
>>
>> Use lambda rather than separate function for asynchronous routine.
>>
>>* [2/6] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait
>>
>> Fall back to using gettimeofday and FUTEX_WAIT if FUTEX_WAIT_BITSET and
>> FUTEX_CLOCK_REALTIME are not available.
>>
>>* [3/6] libstdc++ futex: Support waiting on std::chrono::steady_clock directly
>>
>> Fall back to using clock_gettime (or the sycall directly if necessary)
>> and FUTEX_WAIT if FUTEX_WAIT_BITSET is unavailable.
>>
>>* [4/6] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock
>>
>> No changes
>>
>>* [5/6] libstdc++ futex: Loop when waiting against arbitrary clock
>>
>> New patch. My work on std::condition_variable::wait_until made me realise
>> that there's a risk of indicating a timeout too early when using a
>> non-standard clock.
>>
>>* [6/6] Extra async tests, not for merging
>>
>> Use lambdas rather than separate functions for asynchronous routines.
>>
>>
>>Torvald Riegel had some objections to my design, but did not respond when I
>>attempted to justify it and attempted to change my implementation based on
>>his suggestions (see https://gcc.gnu.org/ml/libstdc++/2018-01/msg00071.html
>>.)
>>
>>It looks like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68519 could
>>apply equally well to __atomic_futex_unsigned::_M_load_when_equal_for.
>>I plan to look at that next.
>>
>>I set up a Debian 4.0 "Etch" system (v2.6.18 kernel, glibc 2.3.6.)
>>Unfortunately, its GCC 4.1.2 is unable to compile GCC master (as of
>>5ba044fc3a443274462527eed385732f7ecee3a8) because hash-map.h appears to be
>>trying to put a reference in a std::pair.)
>
>That's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
>
>>The above patches cherry-pick
>>cleanly back to GCC 7.3, and that version does build after adding a few
>>constants to the system headers. I've confirmed that the lack of support
>>for FUTEX_WAIT_BITSET is detected correctly and that the code falls back to
>>using FUTEX_WAIT. This test also shows that the fallback to calling the
>>clock_gettime system call directly is working too. The async.cc tests all
>>passed.
>>
>>I haven't made any attempt to add entries to the .abilist files. I'm not
>>sure whether I'm supposed to do that as part of the patches, or not.
>
>Changes to gnu.ver linker script are needed, which should be in the patch.

This is the change needed for 'make check-abi' to pass:

--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1902,10 +1902,9 @@ GLIBCXX_3.4.21 {
     _ZNSt7codecvtID[is]c*;
     _ZT[ISV]St7codecvtID[is]c*E;
 
-    extern "C++"
-    {
-      std::__atomic_futex_unsigned_base*;
-    };
+    # std::__atomic_futex_unsigned_base members
+    _ZNSt28__atomic_futex_unsigned_base19_M_futex_notify_all*;
+    _ZNSt28__atomic_futex_unsigned_base19_M_futex_wait_until*;
 
     # codecvt_utf8 etc.
     _ZNKSt19__codecvt_utf8_base*;
@@ -2044,6 +2043,9 @@ GLIBCXX_3.4.26 {
     _ZNSt3pmr20get_default_resourceEv;
     _ZNSt3pmr20set_default_resourceEPNS_15memory_resourceE;
 
+    # std::__atomic_futex_unsigned_base::_M_futex_wait_until_steady
+    _ZNSt28__atomic_futex_unsigned_base26_M_futex_wait_until_steady*;
+
 } GLIBCXX_3.4.25;
 
 # Symbols in the support library (libsupc++) have their own tag.



>Changes to the baseline_symbols.txt files should not be included in
>the patch, those are regenerated later.
>
>
>>
>>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
>> libstdc++ futex: Loop when waiting against arbitrary clock
>> Extra async tests, not for merging
>
>Most of these patches fail to apply because they use spaces where the
>GCC code has tabs. I can fix it, but I'm not sure why the tabs aren't
>in your patches.
>
>
>
>