Like std::latch[1][2]. Originally proposed by N3666, it only became a reality after the atomic wait functionality in C++20. We can't depend on that yet in Qt because a) we don't depend on C++20 yet, and b) the implementations of atomic waiting and std::latch are too recent in the Standard Library implementations (GCC 12, LLVM 12, MSVC 19.28). This implementation therefore builds the functionality from scratch, like the original proposal did[3]. We'll probably keep our implementation for the long run, because it's more efficient than the Standard Libraries' implementations. The MS STL implementation is the closest to ours and to bare OS functionality: uses WaitOnAddress / WakeByAddress as expected, but it generates a bit more code than is necessary. And it's Windows-specific, of course. Both cross-platform implementations (libstdc++ and libc++) do far more work than necessary for platforms that offer a OS futex-like support. Both of them busy-loop waiting for the atomic value to change and then exponentially back off using sched_yield(). Those aren't useful to us, as the majority of our uses are with threads that have just been created and have therefore likely made little progress. They can be actively harmful in some cases. The libc++ implementation is even worse by using std::high_resolution_clock to time this looping up to 64 µs in inline code before making a system call to sleep and wait (and it can't / won't use the latch's address for the futex itself). Both implementations also use an extra atomic out of a global pool (16 in libstdc++, 256 in libc++) to indicate whether there is any waiter on this address and therefore avoid the system call to wake them. See the next commit for an efficient implementation for QLatch. This implementation uses the limited atomic-wait functionality added by the previous commit for platforms that don't support futexes. [1] https://wg21.link/p1135 [2] https://en.cppreference.com/w/cpp/thread/latch/latch [3] https://github.com/ogiroux/atomic_wait/tree/master/include Change-Id: Ib5ce7a497e034ebabb2cfffd1761a3a6ff2598d3 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>