[libcxx-commits] [libcxx] Fix bug in atomic_ref's calculation of lock_free-ness. (PR #93427)
via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Jun 25 07:03:49 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.
+ }
+ }
----------------
EricWF wrote:
I'm not sure I fully understand what you're suggesting.
I think we still want to check that a type that is always lock free is also lock free at runtime.
https://github.com/llvm/llvm-project/pull/93427
More information about the libcxx-commits
mailing list