[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"));
+  if (wait_on_address != nullptr) {
----------------
mstorsjo wrote:

> libc++ seems to have dropped Windows 7 support

That's not true. Libc++ does support Windows 7 - but when building, `_WIN32_WINNT` indicates the lowest version you require at runtime.

So if your toolchain defaults to a higher version, you need to manually define `_WIN32_WINNT` to the lowest version you want to support. llvm-mingw builds with `_WIN32_WINNT` set to Windows 7.

So for things like this, like the example in chrono.cpp, we can choose to either load symbols dynamically, if targeting an older version, or link directly, if we're targeting a new enough version. But in this case, the PR author pointed out that it would require linking in another import library if we'd link directly, which both is extra work on the CMake level, and also translates to extra work for users who statically link in libc++. So as the overhead is near-zero with only loading it the first time it is called, the PR author thought it was simplest to always go with the dynamic loading approach, which sounds reasonable to me.


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