On Thursday, 19 February 2026 05:49:35 Pacific Standard Time Oliver Schädlich
via Std-Proposals wrote:
> There's no guarantee that std::atomic_flag::wait and
> std::atomic_flag::notify_all are lock-free either.

More importantly, there's no guarantee that atomic_wait in any of its variants
is efficient. From experience, it isn't with most types with the three major
Standard Library implementations. You have to choose atomic<int> specifically
to have a chance of it being efficient and even then it won't be.

libstdc++:
std::atomic_flag is backed by a bool, so wait() is NEVER just a futex
std::latch is designed to specifically be able to use futex
std::atomic<int> gets wrapped, so it's just like std::atomic_flag

libc++:
std::atomic_flag is backed by a bool too
std::latch is backed by a ptrdiff_t, so never efficient either
 (that means they are both equally inefficient)
std::atomic<int> appears to wait directly on its own
But all of them have a timed exponential backoff emitted.

MS STL:
std::atomic_flag is backed by a long (32-bit), a size WaitOnAddress() supports
std::latch is backed by a ptrdiff_t, but on Windows that is a supported size
std::atomic<int> is likewise a supported size

See for yourself:
https://gcc.godbolt.org/z/9rY8fxz8j

That's why I wrote my own QLatch.
https://code.qt.io/cgit/qt/qtbase.git/log/src/corelib/thread/qlatch_p.h

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.