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.
