[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:

Sorry, pushed a revision without seeing the comments above. I'll reply to them now.

> Can't we do just `GetModuleHandleW(L"kernel32.dll")` as well?
No, the entire point of API sets was to "hide" functions from their actual containing dlls, separating the "named API" from the actual implementation. If you try and do a GetProcAddress on the functions under kernel32.dll, they won't be found. You need to retrieve the API set using the name of that API set, even if you know which dll it's actually implemented under. The HMODULE returned by LoadLibrary isn't actually a module handle in other words, it's HMODULE-adjacent.

> Then secondly, _if_ `GetModuleHandleW` returns `NULL`, I think it may be considered safe to pass that to `GetProcAddress`, although I'm not sure if any documentation specifically guarantees it?
I'm hunting for a reference on that now. It's guaranteed that if GetProcAddress fails, it returns NULL. Handle types are always validated on Win32 API functions, with error codes if they're not valid. There are never exceptions, much less crashes for invalid "standard" handles, that would be considered a defect in Windows that Microsoft would fix. There's simply an enormous body of code going back 25 years that would crash and burn if this wasn't the case, but I'm trying to find a reference in today's documentation that states this is the case. I'm sure I've read this guarantee somewhere central in the past, but there's been so many revisions to MSDN documentation over the years it's not always easy to track down.

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