Re: [PATCH] Add C++2a synchronization support

[Thomas Rodgers <trodgers@redhat.com>]

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.

>>+	return;
>>+
>>+      if constexpr (__platform_wait_uses_type<_Tp>::__value)
>>+	{
>>+	  __platform_notify((__platform_wait_t*)(void*) __addr, __all);
>>+	}

<snip>

>>+    struct __platform_semaphore
>>+    {
>>+      using __clock_t = chrono::system_clock;
>>+
>>+      __platform_semaphore(ptrdiff_t __count) noexcept
>
> Should this constructor be explicit?
>

Yes.

>>+      template<typename _Duration>
>>+	_GLIBCXX_ALWAYS_INLINE bool
>
> Do we really need this to be always_inline?
>
Probably not, copypasta from elsewhere in the same file.

>>+	__try_acquire_until_impl(const chrono::time_point<__clock_t>& __atime) noexcept
>>+	{
>>+	  auto __s = chrono::time_point_cast<chrono::seconds>(__atime);
>>+	  auto __ns = chrono::duration_cast<chrono::nanoseconds>(__atime - __s);

<snip>

>>+    template<typename _Tp>
>>+      struct __atomic_semaphore
>>+      {
>>+	static constexpr size_t _S_alignment = __alignof__(_Tp);
>>+
>>+	__atomic_semaphore(_Tp __count)
>
> Should this be explicit?
>
Yes.

>>+    private:
>>+      alignas(_S_alignment) _Tp _M_a;
>
> Could this just use alignas(__alignof__(_Tp)) _Tp here? There's no
> need for the _S_alignment constant if it's only used in one place.
>
Yes.

>>+    };
>>+
>>+#ifdef _GLIBCXX_REQUIRE_POSIX_SEMAPHORE
>>+  template<ptrdiff_t __least_max_t>
>
> Rename __least_max_t here too.
>
>>+    using __semaphore_base = __platform_semaphore<__least_max_t>;
>>+#else
>>+#  ifdef _GLIBCXX_HAVE_LINUX_FUTEX
>>+  template<ptrdiff_t __least_max_t>
>>+    using __semaphore_base = std::conditional<(__least_max_t > 0
>
> This should use conditional_t<> not conditional<>::type.
>
> The least-max_value can't be negative. If it's zero, can't we use a
> futex or semaphore? So the '__least_max_t > 0' condition is wrong?
>

Yes.

>>+					      && __least_max_t < std::numeric_limits<__detail::__platform_wait_t>::max()),
>
> Should that be <= rather than < ?
>

Likely.

>>+					      __atomic_semaphore<__detail::__platform_wait_t>,
>>+					      __atomic_semaphore<ptrdiff_t>>::type;
>>+				            // __platform_semaphore
>>+#  else

<snip...>