[libcxx-commits] [libcxx] [libc++] Improve performance of std::atomic_flag on Windows (PR #163524)

[Roger Sanders via libcxx-commits]

================
@@ -101,6 +105,46 @@ static void __libcpp_platform_wake_by_address(__cxx_atomic_contention_t const vo
   _umtx_op(const_cast<__cxx_atomic_contention_t*>(__ptr), UMTX_OP_WAKE, __notify_one ? 1 : INT_MAX, nullptr, nullptr);
 }
 
+#elif defined(_WIN32)
+
+static void
+__libcpp_platform_wait_on_address(__cxx_atomic_contention_t const volatile* __ptr, __cxx_contention_t __val) {
+  // WaitOnAddress was added in Windows 8 (build 9200)
+  static auto wait_on_address = reinterpret_cast<BOOL(WINAPI*)(volatile void*, PVOID, SIZE_T, DWORD)>(
+      GetProcAddress(GetModuleHandleW(L"api-ms-win-core-synch-l1-2-0.dll"), "WaitOnAddress"));
+  if (wait_on_address != nullptr) {
----------------
RogerSanders wrote:

I'll add though, if we do go the route of dropping Win7 support and pushing the link library down the line, I'm happy to do that if I can get some guidance on how to do it in a way that'd be accepted. I'm familiar with pragma lib, but the mingw library merge I'd want more advice on.

If I get more time, I might dig into the Microsoft STL implementation on how they were handling the dynamic loading issues though. They were essentially doing the exact same thing with conditionally loading the API at runtime, because they did support this on Win7/Win8 concurrently. I'm curious what they did about the dll unload issue. I honestly wouldn't be shocked if they just leaked the dll handle. I can't see a way around it right now.

https://github.com/llvm/llvm-project/pull/163524