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

[Louis Dionne 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) {
----------------
ldionne wrote:

I must say that I find something like `LoadLibraryW(L"api-ms-win-core-synch-l1-2-0.dll")` on a code path that performs a simple atomic wait to be very scary. We also involve the function-local static support in libc++abi which involves an atomic variable as well (although not in a way that is problematic i.e. recursive at the moment).

Still, I think this is not ideal. Also, we don't support Windows 7, but we also don't *not* support it. We should update our documentation to specify a minimum version we support. @mstorsjo would you be willing to do that? Since extended support for Windows 7 has ended on January 2020, I think it's difficult to make an argument to support it here. Thoughts?

Other than this, the patch looks reasonable IMO!

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