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

[Martin Storsjö 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"));
----------------
mstorsjo wrote:

> 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.

This is a tangent here, but wanted to address some details here: I agree that the point of the API sets was to avoid tieing executables to the specific DLL that originally implements a function - but if you look up the actual DLL, you _will_ find the function pointer there as well. As far as I know about the implementation of how the API sets work, the symbol _will_ be resolveable with `GetProcAddress` from one concrete DLL as well.

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.

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