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

[Thiago Macieira <thiago.macieira@intel.com>]

On Friday, 26 February 2021 16:18:33 PST Ville Voutilainen wrote:
> There's nothing new in that either. I do, however, wonder how
> dangerous using the current
> implementation actually is? Anyhoo, almost regardless of that, we have
> had situations like
> that before. While we don't exactly want to repeat them (std::regex
> in.. gcc8? comes to mind here),
> I'm not entirely convinced that we are talking about a showstopper problem
> here.

The danger is not how they're implemented today. The danger is the change. 
That would imply a pre-change wait() is never woken up by a post-change 
notify() or vice-versa. That in turn causes deadlocks in latches, barriers and 
semaphores.

Depending on how the two implementations are achieved, the outcome may also 
depend on the order of waits and notifies and which side of the change is 
doing which operation. That in turn leads to heisenbugs in production which a 
developer will almost never see.

> > Fair enough, but we know we are not in the sunshine case. We know now,
> > before the release, that it WILL change and cause silent
> > incompatibilities. Does that change the conclusion?
> 
> Do tell me what those silent incompatibilities really are. If they're
> differences in inlined
> code baked into client applications, I'm not sure I see what's so
> earth-shattering there.

1) size of structures change
2) default template parameters change (silent ODR violations)
3) data protocol changes (whether certain static members are used or not)

> > How about the other way around: only enable the new, experimental code if
> > the user defines _GLIBCXX_I_WANT_EXPERIMENTAL before the #includes?
> 
> That seems drastic. We wouldn't get pretty much any use coverage of
> any new code,
> and that would just sweep the rug from under the whole idea of
> feature-testing macros,
> half of which is allowing bold users to adopt new facilities early.

Those goals seem incompatible. If the feature is experimental and not to be 
used in production, then we don't want users to adopt the facilities early. We 
want them to wait until we declare that it's no longer experimental.

> Now they would need
> to fall back to seventeen different implementation-specific ways to
> opt in to that adoption,
> which takes us back a decade.

I'm the last person to want those multiple ways of detecting when a feature is 
safe to be used. You know that. We specifically made it so Qt would NOT use 
any new C++14 or C++17 feature from the compiler or the Standard Library until 
the macros were present, thus helping force a certain compiler vendor to adopt 
the feature macros.

But this is exactly the issue: I *don't* want to have to know that 
__cpp_lib_atomic_wait == 201907L is only acceptable if __GNUC_MAJOR__ > 11.

> Please explain how your concerns about atomic waits
> are *anywhere near* the cost of doing that?

Which part? The part about why I think the implementation should be different? 
Or the part in which making a change causes future problems?

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