> 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.

If they are such a problem, I'd fully support your effort to remove them from the API entirely.

Then you could propose a type that uses atomics and has the notify/wait semantics you deem safe and necessary, that has no UB and is complete and proper because it is a type designed for that specific purpose, and not functions bolted onto something that was not originally intended to be used in such a way.



> On Jan 14, 2026, at 8:11 PM, Ryan P. Nicholl via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 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] <mailto: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.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals