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

Pushed a revision which factors out the extra logic into the helper function. Definitely makes it cleaner on use.

> Now specifically for these functions, you're right, they're not found in `kernel32.dll`. I had a look around, and it turns out that they're in `kernelbase.dll`. But if nothing documents that, I agree that it's probably best to only refer to them through the API set name.

Thanks for that clarification, it's good to know. I'm also glad I was wrong about that. The fact that Windows does in fact just use the real module handle makes me feel better about the implementation - I was imagining the kind of spaghetti LoadModule/GetProcAddress would need to have to support "hiding" the functions using "fake" HMODULE handles - yuck. In retrospect, it would have also violated their own documentation, which (now) definitively states that a HMODULE is just the base address of the module in memory.

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