C++ Logo

std-proposals

Advanced search

Re: [std-proposals] atomic_compare_exchange_and_notify

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Wed, 14 Jan 2026 21:39:12 +0000
On Wed, 14 Jan 2026 at 20:10, Ryan P. Nicholl <rnicholl_at_[hidden]>
wrote:

> When I say it's not possible to implement, what I mean is not that it
> can't be implemented, but rather that it can't be implemented using the C++
> standard library without UB.
>
> libc++ implements std::latch without any issue, so this clearly is
> possible to implement correctly.
>
> However, libc++ implementation of std::latch is relying on something that
> the C++ standard library doesn't promise, namely `void
> __cxx_atomic_notify_all(void const volatile*)` in libc++ doesn't seem to
> require that the atomic object actually *exist* at that address. However,
> notify_all from C++ library doesn't give any such guarantee per standard,
> even if it works in libc++. Also, __atomic_contention_address could
> interact with atomic lifetime somehow if the implementation wanted to.
>
> Since this is clearly implementable using the existing libc++
> implementation as an example, I think it should be added to the standard if
> possible.
>
> Really, all I need is a promise that I can notify an address which the
> atomic object might already be destroyed, that could also be a DR on
> existing C++ standards if it was permitted for the existing freestanding
> notify functions. However, I'm not sure if that could break any "clever"
> implementations of atomic. So my inclination would be adding
> atomic_compare_exchange_and_notify_* which is not required to be
> supported for types which are not lock-free.
>

lock-free is the wrong condition though.

atomic<bool> is lock-free on my platform, but it doesn't use a futex.

Received on 2026-01-14 21:39:30