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.
OpenBSD doesn't either:
Nor DragonFly BSD:
Nor macOS as far as I know:
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.