We are talking "efficient" here, but are we talking worst-case or average?
Querying for "is_always_lockfree()" can be useful as a (somewhat crude)
check that the worst case scenario is bounded.
If the implementation is "good but with the wrong trade-offs for my problem
domain", then it is not a QoI.

// Robin

On Mon, Feb 16, 2026, 19:09 Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Mon, 16 Feb 2026 at 13:30, Vittorio Romeo via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Consider the following pattern:
>>
>> std::atomic_flag flag = ATOMIC_FLAG_INIT;
>>
>> // Thread A
>> flag.test_and_set(std::memory_order_release);
>> flag.notify_all();
>>
>> // Thread B
>> flag.wait(false, std::memory_order_acquire);
>>
>> It can nicely be simplified with a latch:
>>
>> std::latch latch{ 1 };
>>
>> // Thread A
>> latch.count_down();
>>
>> // Thread B
>> latch.wait();
>>
>> This seems a direct improvement, but unfortunately it really isn't:
>> 1. There's no guarantee that `std::latch` uses atomics under the hood
>> 2. There's no guarantee that `std::latch` is "lock-free"
>>
>
> There's no guarantee that std::atomic_flag::wait and
> std::atomic_flag::notify_all are lock-free either.
>
>
>
>> 3. All functions in the first pattern were `noexcept`, while none of the
>> `latch`'s functions are
>>
>> I would like to be able to use the higher-level pattern using
>> `std::latch` without sacrificing performance nor exception safety.
>>
>
> Does it matter whether it uses atomics? Surely what matters is that it's
> efficient, not whether that efficiency is achieved using atomics or using
> magic. If it's not as efficient as it could be using atomics, isn't that
> just a bad implementation?
>
>
>
>>
>> It would be nice if there was a way to detect at compile-time if
>> `std::latch` uses atomic operations under the hood and is guaranteed to not
>> throw.
>> Something like `std::atomic<T>::is_always_lock_free`, but for latches.
>>
>> Ideas:
>> - std::latch::is_always_lock_free
>>
>
> What would this mean? Since wait and notify can use locks, none of latch's
> members can really be lock-free.
>
>
>> - std::latch::uses_atomic_operations
>>
>
> Is this really useful? A uses_atomic_operations constant wouldn't
> guarantee that it's efficient. It could use atomics and be inefficient, or
> it could be efficient without using atomics.
>
>
>
>> - std::latch::is_atomic
>>
>
> What would this mean? std::latch already guarantees not to introduce data
> races, and the counter decrement in count_down is already guaranteed to be
> atomic.
>
>
>>
>> Additionally, it would be nice if the Standard mentioned that while
>> `std::latch`'s functions cannot be generally be marked `noexcept`, they
>> are guaranteed to never throw if the above trait is true.
>>
>
> Could this be solved by just having implementations use conditional
> noexcept on std::latch member functions?
>
> I think what you're asking for latch to be efficient, which is QoI, and to
> be able to tell if latch is nothrow, which you want to use some new traits
> for, but just testing noexcept(declval<latch>().count_down()) &&
> noexcept(declval<latch>().wait()) seems sufficient for that.
>
>
>> What do you think?
>> Worth writing a paper?
>>
>> Cheers,
>>
>> Vittorio Romeo
>> https://vittorioromeo.com
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>