C++2a synchronisation inefficient in GCC 11

[Thiago Macieira]

On Friday, 26 February 2021 03:19:02 PST Jonathan Wakely wrote:
> > 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.

Hello Jonathan

Thank you for replying.

The problem is not the export or not export, it's that the protocol/method is 
locked down. We cannot change it in a future version, like changing the number 
of __waiter objects in the __waiters::_S_for function. Since that code gets 
inlined into every executable that uses it, future versions are bound to use 
the exact same selection until we break ABI.

> 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.

Oh? That's not a really widely understood fact. I see people using C++20 right 
now all the time in the cpplang slack and no one seems to be worried that 
support is experimental.

Still, what I'm proposing is that we minimise the fallout right now.

> >  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.

Hmm... I didn't test increasing to UINT_MAX after my change to 
__platform_wait_uses_type. I guess it should just work.

> 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.

Thanks, but I still propose we hide it better.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering