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@lists.isocpp.org> wrote:



On Wed, 14 Jan 2026, 00:55 Ryan P. Nicholl via Std-Proposals, <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals