On Fri, 22 Mar 2024 at 16:57, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote:
>
> I wonder about that. The disadvantage of only supporting LKMM atomics is
> that we'll be incompatible with third party code, and we don't want to
> be rolling all of our own data structures forever.
Honestly, having seen the shit-show that is language standards bodies
and incomplete compiler support, I do not understand why people think
that we wouldn't want to roll our own.
The C++ memory model may be reliable in another decade. And then a
decade after *that*, we can drop support for the pre-reliable
compilers.
People who think that compilers do things right just because they are
automated simply don't know what they are talking about.
It was just a couple of days ago that I was pointed at
https://github.com/llvm/llvm-project/issues/64188
which is literally the compiler completely missing a C++ memory barrier.
And when the compiler itself is fundamentally buggy, you're kind of
screwed. When you roll your own, you can work around the bugs in
compilers.
And this is all doubly true when it is something that the kernel does,
and very few other projects do. For example, we're often better off
using inline asm over dubious builtins that have "native" compiler
support for them, but little actual real coverage. It really is often
a "ok, this builtin has actually been used for a decade, so it's
hopefully stable now".
We have years of examples of builtins either being completely broken
(as in "immediate crash" broken), or simply generating crap code that
is actively worse than using the inline asm.
The memory ordering isn't going to be at all different. Moving it into
the compiler doesn't solve problems. It creates them.
Linus
