[libcxx-commits] [libcxx] Fix bug in atomic_ref's calculation of lock_free-ness. (PR #93427)

Damien L-G via libcxx-commits libcxx-commits at lists.llvm.org
Tue Jun 25 08:27:11 PDT 2024


================
@@ -18,9 +18,25 @@
 #include <concepts>
 
 #include "test_macros.h"
+#include "atomic_helpers.h"
 
 template <typename T>
-void check_always_lock_free(std::atomic_ref<T> const a) {
+void check_always_lock_free(std::atomic_ref<T> const& a) {
+  using InfoT = LockFreeStatusInfo<T>;
+
+  if (InfoT::status_known) {
+    constexpr LockFreeStatus known_status = InfoT::value;
+
+    static_assert(std::atomic_ref<T>::is_always_lock_free == (known_status == LockFreeStatus::always),
+                  "is_always_lock_free is inconsistent with known lock-free status");
+    if (known_status == LockFreeStatus::always) {
+      assert(a.is_lock_free() && "is_lock_free() is inconsistent with known lock-free status");
+    } else if (known_status == LockFreeStatus::never) {
+      assert(!a.is_lock_free() && "is_lock_free() is inconsistent with known lock-free status");
+    } else {
+      assert(a.is_lock_free() || !a.is_lock_free()); // This is kinda dumb, but we might as well call the function once.
+    }
+  }
----------------
dalg24 wrote:

> I think we still want to check that a type that is always lock free is also lock free at runtime.

You're right.

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


More information about the libcxx-commits mailing list