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.) 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. 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 libstdc++-v3/include/bits/atomic_futex.h | 89 ++++++++++-- libstdc++-v3/src/c++11/futex.cc | 113 +++++++++++++++ libstdc++-v3/testsuite/30_threads/async/async.cc | 172 +++++++++++++++++++++++ 3 files changed, 364 insertions(+), 10 deletions(-) -- 2.11.0 BrightSign considers your privacy to be very important. The emails you send to us will be protected and secured. Furthermore, we will only use your email and contact information for the reasons you sent them to us and for tracking how effectively we respond to your requests.
