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

[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) {
----------------
Alcaro wrote:

Good point, I forgot that LoadLibrary is scary in DllMain. Fair chance user code calls this in a global ctor, and even if not, `static auto module_handle`'s dtor will run in DllMain; FreeLibrary [is explicitly documented](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-freelibrary) as unsafe.

GetModuleHandleEx (and GetProcAddress) are not documented unsafe, but absense of evidence doesn't prove anything.

<br>

However, if we decide to drop 7, [there's another problem](https://github.com/llvm/llvm-project/pull/163524#issuecomment-3406028126):

> If we were to try and do the same thing as std::chrono, the real problem is the linking - there's a separate Synchronization.lib to pull in for these exports, we don't get them in kernel32.lib. If libc++ was being linked statically, that'd push the dependency down to the linking module I believe, unless there's a way around that being used in libc++ currently that I'm not aware of.

It's easy to work around on msvc/clang-cl with #pragma comment lib, but there's no such thing in mingw.

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