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

At this point I am wondering if you are being deliberately obtuse. I suggest reading the comments at https://codebrowser.dev/glibc/glibc/sysdeps/nptl/lowlevellock.h.html around __lll_unlock to understand the problem with C++ atomic_notify_* operations.

Pthread/UNIX specification requires​ that concurrent t1[lock()spawn(t2)unlock()] and t2[lock()unlock()destroy()] sequence be valid. C++ standard has a similar requirement for std::mutex/std::latch. I think this cannot be implemented using std::atomic with the current wording due to the "dereference" wording, unfortunately.

--
Ryan P. Nicholl
Tel: (678)-358-7765
On Wednesday, January 14th, 2026 at 16:46, Jonathan Wakely <cxx_at_[hidden]> wrote:
> 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.