On Thursday, 19 August 2021 22:45:09 PDT Marko Mäkelä via Std-Proposals wrote:
> I believe that the code works wherever std::atomic::wait() is available
> (currently, this includes MSVC on Windows, GCC or Clang on Linux with
> libstdc++-11). There is also a fallback implementation for C++11, using
> futex system calls on Linux or OpenBSD.

Which is your best implementation by far. Aside from looping on CAS, which you
should never do.

> I believe that it would be useful if the C++ standard library included
> mutex or rw-lock primitives that build upon std::atomic. I would
> appreciate feedback and advice how this could be converted into a formal
> proposal for inclusion in the standard.

As Ville said, you're going to have to do a lot of explaining here.
Explicitly, you'll need to explain why this type exists in addition to
std::mutex, and give a dozen examples on how to choose one or the other.

From experience, being the maintainer of QMutex, I can tell you that your
simple mutex is what *I* want, and the result is that all QMutex are that.
There's no way to access a pthread_mutex_t from the Qt API. There's no
intention on providing compatibility.

std::mutex, on the other hand, explicitly provided that compatibility. So now
legacy exists and we need to explain why one and not the other.

> Native mutexes or rw-locks tend to have huge storage requirements
> (sizeof(pthread_mutex_t)==48 on 64-bit GNU/Linux) and may have
> unsuitable semantics: When a lock is acquired by Thread A and ownership
> is passed an unspecified thread (for example, one that will be invoked
> on asynchronous I/O completion), we would want a subsequent acquisition
> by Thread A to block until the lock has been released (by some other
> thread). In pthread_mutex_t, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP can
> be used to enable recursion, but there does not appear to be a portable
> way to disable it.

Please note that atomic waits are not free either. They may have a hidden cost
behind the scenes, especially if the used type in std::atomic is not suitable
for the OS API. And since the specification does not require that the value
*change* before waiting/waking, those will always have a higher overhead than
the futex.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering