On Wed, Jan 14, 2026 at 3:42 PM Ryan P. Nicholl via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.
>
>
> std::mutex and condition_variable can't be implemented using only the guarantees in the standard provided by std::atomic either.
>
> I'm not sure how concerning this is in practice, given pthreads (which is usually used to implement mutex) says as follows:
>
> The pthread_mutex_destroy() function shall destroy the mutex object referenced by mutex; the mutex object becomes, in effect, uninitialized. An implementation may cause pthread_mutex_destroy() to set the object referenced by mutex to an invalid value. A destroyed mutex object can be reinitialized using pthread_mutex_init(); the results of otherwise referencing the object after it has been destroyed are undefined.
>
> It shall be safe to destroy an initialized mutex that is unlocked. Attempting to destroy a locked mutex results in undefined behavior.
>
> Seems the pthread mutex implementation guarantees this is safe, but the C++ standard, as best I can tell, does not provide a way to implement either behavior using std::atomic.
>
> Looking at MUSL, it seems like it's using a very similar strategy to libc++ for implementing pthread_mutex_unlock();
>
> LeaveCriticalSection has the same behavior.
>
> It looks like all major implementations use this type of "mutate and notify" operation internally, but the standard library doesn't expose any way to do this which is not relying on what seems like UB.
>
> If there is something somewhere which defines this as working, I'm interested to know what it would be.
>
> I do not think you can (legally) implement std::mutex using std::atomic in a way that doesn't rely on these behaviors.

You aren't supposed to be able to either. It is not a design goal for
`atomic` to be a kind of fundamental building block upon which all
other threading behavior can be built. It's meant to just handle
atomic modifications of memory; that's mostly it.

I don't think it's a good idea to try to turn `atomic` into such a
fundamental building block either. If such a thing is needed, some
minimal thread synchronization primitive upon which all others can be
layered, then it's better to design that thing from scratch.