[PATCH] Add C++2a synchronization support

[Jonathan Wakely]

On 11/05/20 08:43 -0700, Thomas Rodgers wrote:
>
>Jonathan Wakely writes:
>
>> On 09/05/20 17:01 -0700, Thomas Rodgers via Libstdc++ wrote:
>
><snip>
>
>>>+#include <iostream>
>>
>> <iostream> shouldn't be here (it adds runtime cost, as well as
>> compile-time).
>>
>Oversight, not removed after debugging it.
>
><snip>
>
>>
>> Can't this just be __old instead of *std::__addressof(__old) ?
>>
>Copypasta from elsewhere in the same class, I believe. I'll change it.
>
><snip>
>
>>
>> Isn't alignas(64) already implied by the first data member?
>>
>
>Yes
>
>>>+    {
>>>+      int32_t alignas(64) _M_ver = 0;
>>>+      int32_t alignas(64) _M_wait = 0;
>>>+
>>>+      // TODO make this used only where we don't have futexes
>>
>> Don't we always need these even with futexes, for the types that don't
>> use a futex?
>>
>
>If we have futexes, we can use the address of _M_ver to wake
>_M_do_wait() instead of using a condvar for types that don't use a
>futex directly.
>
>>>+      using __lock_t = std::unique_lock<std::mutex>;
>>+      mutable __lock_t::mutex_type _M_mtx;
>>>+
>>>+#ifdef __GTHREAD_COND_INIT
>>>+      mutable __gthread_cond_t _M_cv = __GTHREAD_COND_INIT;
>>>+      __waiters() noexcept = default;
>>
>> If we moved std::condition_variable into its own header (or
>> <bits/std_mutex.h>, could we reuse that here instead of using
>> __gthread_cond_t directly?
>>
>Yes, I started down that route initially, I could revisit it in a future
>patch as part of also making it's use only necessary when the platform
>doesn't support futex.
>
>>>+    __atomic_notify(const _Tp* __addr, bool __all) noexcept
>>>+    {
>>>+      using namespace __detail;
>>>+      auto& __w = __waiters::_S_for((void*)__addr);
>>>+      if (!__w._M_waiting())
>>
>> When __platform_wait_uses_type<_Tp> is true, will __w._M_waiting()
>> ever be true? Won't this always return before notifying?
>>
>> Is there meant to be a __waiter constructed here?
>>
>
>__waiter (an RAII type) is constructed in the __atomic_wait(), that
>increments the _M_wait count on the way into the wait, and decrements it
>on the way out, __atomic_notify checks to see if that count is non-zero
>before invoking the platform/semaphore notify because it is cheaper
>to do the atomic load than it is to make the syscall() when there are no
>waiters.

Doh, yes of course.