> I definitely think it would be nice to have a C++ type that exposes futex functionality directly with no additional overhead, but std::atomic is not that type.

Agree. And its not the type for any kind of functionality other than simple atomic operations.

IMO, `std::atomic` should not have notify/wait semantics at all, but that cat's out of the bag. I wish there were a way to remove them and add another class with that functionality, but that would be a backward-breaking change, and we are very reluctant to make those kinds of changes.

Basically, these are separate concerns and should not be part of the same class.

As it stands, `std::atomic_ref` also inherits this madness, which means you can't even do the "safe" thing and put builtins into shared memory and use `std::atomic_ref` safely. Yes, you bypass the implicit lifetime issues, but now you have an interface that is very easy to use in contexts that are almost certain to cause real damage.

I understand the C++ stance on processes very well, but the only place we mention processes in the standard is when we clearly state that using atomics across process boundaries in shared memory is a supported use case.

I'd be very much opposed to adding even more junk to `std::atomic`, no matter how supposedly useful.

If we want to add stuff to make using atomics easier - fine - add them as separate APIs. Please don't keep making them more difficult to use correctly.



> On Jan 14, 2026, at 6:07 AM, Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> On Wed, 14 Jan 2026, 00:55 Ryan P. Nicholl via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>> It has come to my attention that it isn't possible to implement data structures like std::latch or a uselock using the C++ atomic library without undefined behavior.
>>
>> Namely, std::latch guarantees that count_down doesn't cause a race even if there are waiters, this isn't possible to implement on the abstract machine unless the notification can be safely executed atomically with the value set. Ordinary notify_one has undefined behavior if it races with the destructor of the atomic object.
>
>
> That doesn't mean it isn't possible to implement. It means you have to be careful how you use it.
>
> Most types don't guarantee that you can destroy them while another thread is still using them, this isn't specific to std::latch. I think "it isn't possible to implement" is framing this completely wrong.
>
> It's also not true, you could implement it with a std::mutex and a std::condition_variable if you want to guarantee that waiters do not wake before a notify is complete.
>
>>
>> Of course, it's possible to implement std::latch using things like SYS_futex, so this isn't impossible to implement per se, only impossible to implement using the C++ standard library without relying on undefined behavior.
>
> It's possible using FUTEX_WAKE_OP, but what about non-linux platforms?
>
>>
>> I would propose adding atomic_compare_exchange_and_notify. This would have the same behavior as atomic compare_exchange followed by notify, except that it doesn't cause undefined behavior if a waiter unblocks on the new value and destroys the atomic, which could race with notify.
>
> How would that work for std::atomic<long long> which doesn't use a futex directly?
>
> I definitely think it would be nice to have a C++ type that exposes futex functionality directly with no additional overhead, but std::atomic is not that type.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals