[patch libstdc++] Optimize synchronization in std::future if futexes are available.

[Jonathan Wakely]

On 17/01/15 15:54 -0700, Sandra Loosemore wrote:
>On 01/17/2015 03:36 PM, Jonathan Wakely wrote:
>>On 17/01/15 15:22 -0700, Sandra Loosemore wrote:
>>[snip snip]
>>>I'm getting a different series of build errors with this patch --
>>>starting with
>>>
>>>In file included from
>>>/scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:27:0:
>>>
>>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:221:5:
>>>error: 'mutex' does not name a type
>>>    mutex _M_mutex;
>>>    ^
>>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:222:5:
>>>error: 'condition_variable' does not name a type
>>>    condition_variable _M_condvar;
>>>    ^
>>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:
>>>In member function 'unsigned int
>>>std::__atomic_futex_unsigned<_Waiter_bit>::_M_load(std::memory_
>>>order)':
>>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:230:7:
>>>error: 'unique_lock' was not declared in this scope
>>>      unique_lock<mutex> __lock(_M_mutex);
>>>      ^
>>>and going on for several screenfuls.
>>
>>Odd, that should already be fixed at rev 219799.
>>
>>Are you still at a revision older than that?
>
>My source tree is at r219802 now.

My fault, this additional chunk is needed alongside the patch I sent
earlier:

--- a/libstdc++-v3/include/bits/atomic_futex.h
+++ b/libstdc++-v3/include/bits/atomic_futex.h
@@ -35,7 +35,7 @@
 #include <bits/c++config.h>
 #include <atomic>
 #include <chrono>
-#if !defined(_GLIBCXX_HAVE_LINUX_FUTEX)
+#if ! (defined(_GLIBCXX_HAVE_LINUX_FUTEX) && ATOMIC_INT_LOCK_FREE > 1)
 #include <mutex>
 #include <condition_variable>
 #endif

What I sent earlier causes your target to use std::mutex and
std::condition_variable, but without the bit above the headers aren't
included.

>>>Maybe the patch(es) causing all these problems should be reverted
>>>until the breakage is tracked down and fixed and regression-tested on
>>>a variety of targets?  It's not really blocking me at the moment, but
>>>it seems unfortunate that trunk is so unstable as we're entering Stage
>>>4.....

Torvald, if the extra change above doesn't fix it (although it should
do) then maybe it should be reverted until it can be tested more
widely.