Re: C++2a synchronisation inefficient in GCC 11

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Thu, 25 Feb 2021 at 23:28, Thiago Macieira via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> Hello all
>
> I was investigating the implementation of std::atomic<T>::wait to use inside
> my own code (Qt's QMutex and QSemaphore), when I realised that it has
> huge inefficiencies. Since everything in this implementation is inline and,
> once released, it will tie our hands until the next ABI break (libstdc++.so.

That's not true. By not committing to exporting these symbols from
libstdc++.so now, we can move them into the library later once the
design is stable.

C++20 support is experimental and not stable. If you compile it with
GCC 11 you can't expect to link it to C++20 code compiled with GCC 12.
So for GCC 12 (or a later version) we could replace the inline
functions with non-inline code in libstdc++.so and commit to that
being stable.

So actually this gives us more freedom to change it later.

> 7). And no, inline namespaces and ABI tags are no different than ABI breaks,
> they only make the ABI break more or less silent in the process.
>
> Here's a summary of the findings:
>
>  1) everything is inline
>  2) futex code is still behind a lot of code calling into std::_Hash_bytes
>  3) other int-sized (incl. enums) atomics don't use futex

Yup, including unsigned ints, and longs on ILP32 targets.

>  4) std::latch and std::counting_semaphore defaults preclude from using
>     futex on Linux

Yes, I've suggested that we should use INT_MAX (or maybe UINT_MAX) as
the default, so they fit in the futex range.


I'm not working today, so I'll read the rest and respond to the test
another time.

tl;dr this code is experimental and expected to change, so is inline
for a reason.