[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"));
----------------
RogerSanders wrote:

Ehh, couldn't find a written reference, so I've changed the code again to avoid the use of GetProcAddress on a NULL HMODULE. I'm sure it's written down somewhere, or was once upon a time, but it's no big deal to protect against it here, so I've pushed a change to do that.

And before someone asks, we can safely assume nullptr == NULL, like is done in the case GetProcAddress fails. Sir Raymond Chen has canonized that:
https://devblogs.microsoft.com/oldnewthing/20180307-00/?p=98175



> * That's certainly possible, but what if some other thread loads or unloads the relevant DLL between the first call to each relevant function, so we end up with mismatched Wait/Wake? And what if someone unloads the DLL after we've GetModuleHandle'd it? That stuff is probably safe in practice, but it's definitely scary.
> * (Nitpick: kernel32 isn't the only module that's always loaded - you forgot ntdll)



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