On Wed, 14 Jan 2026 at 22:33, Ryan P. Nicholl <rnicholl_at_[hidden]>
wrote:

> It seems silly to not support adding this behavior.
>
> First, C++ is supposed to be "Zero overhead". If I cannot implement a
> customized mutex with std::atomic, it has mostly failed on that point.
>

Nonsense. std::atomic does not represent everything in C++.

If you want a zero overhead abstraction around a futex, you can do that.
Complaining because std::atomic is not that abstraction is silly, it never
claimed to be that.



>
> I expect to be able to implement a mutex, the same way I can implement my
> own vector type to customize the behavior.
>
> I would not support such a change.
>
>
> Any reasoning other than no?
>

I've made several objections already.

I do not like operating on objects outside their lifetime. You haven't
responded to my question about addresses that are no longer part of the
address space. I would expect futex to return EFAULT in that case.

I do not agree that this actually could be added to std::atomic, or to the
std::atomic specialization for integers, or even to std::atomic<int> on any
platform except Linux.

I do not think this is necessary functionality for std::atomic.

If you need something that is closer to a futex with less overhead and
exposing details of futexes (like the address being allowed to be invalid)
then use a futex.




> All implementations already do this, seems reasonable to me to extend what
> can be done with well defined C++. I'm not sure if there are any
> implementations that *don't* allow this,
>

I already said FreeBSD doesn't seem to.
https://man.freebsd.org/cgi/man.cgi?query=_umtx_op&apropos=0&sektion=2&manpath=FreeBSD+16.0-CURRENT&arch=default&format=html
OpenBSD doesn't either:
https://man.openbsd.org/futex
Nor DragonFly BSD:
https://man.dragonflybsd.org/?command=umtx&section=2
Nor macOS as far as I know:
https://developer.apple.com/documentation/os/os_sync_wake_by_address_any



> but I guess one not allowing it would be grounds to avoid doing so. But I
> think we should DR this if all implementations allow it, and all the ones
> I've checked do.
>
>
Did you check anything that isn't Linux or Windows?



> It's also kind of unlikely that an implementation will *not* allow notify
> on destroyed object, since that operation is required to implement both
> pthread_mutex and std::mutex in a standard compliant way.
>

I don't agree with that claim either. pthread_mutex_unlock does not support
this, unlocking must happen before destroying.


>
> It is theoretically possible that a platform only uses that implementation
> for std::mutex and uses a different implementation for non-mutex notify,
> but I am not aware of any such implementations existing.
>