[libcxx-commits] [libcxx] [libc++] P0718R2: Implementation of std::atomic<shared_ptr<T>> and std::atomic<weak_ptr<T>> (PR #194215)

[Vladislav Semykin via libcxx-commits]

================
@@ -0,0 +1,805 @@
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP___MEMORY_ATOMIC_SHARED_PTR_LOCK_FREE_H
+#define _LIBCPP___MEMORY_ATOMIC_SHARED_PTR_LOCK_FREE_H
+
+#include <__atomic/atomic_sync_lite.h>
+#include <__atomic/check_memory_order.h>
+#include <__atomic/memory_order.h>
+#include <__atomic/support.h>
+#include <__atomic/to_failure_order.h>
+#include <__atomic/to_gcc_order.h>
+#include <__config>
+#include <__cstddef/nullptr_t.h>
+#include <__memory/shared_count.h>
+#include <__utility/move.h>
+
+#include <cstdint>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+_LIBCPP_PUSH_MACROS
+#include <__undef_macros>
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+#if _LIBCPP_STD_VER >= 20 && _LIBCPP_HAS_THREADS
+
+template <class _Tp>
+class shared_ptr;
+
+template <class _Tp>
+class weak_ptr;
+
+template <class _Tp>
+struct atomic;
+
+// __ctrl_ word layout (8 bytes):
+//   bits 0..1    always zero (CBs are at least 4-byte aligned)
+//   bits 2..47   control-block pointer
+//   bits 48..63  16-bit local refcount (Williams split-refcount)
+// Bits 48..63 are available on both DWCAS-capable ISAs (x86-64 without LAMA,
+// AArch64 without LVA): user-space pointers stay within 48 bits.
----------------
ViNN280801 wrote:

This is my big mistake, sorry for that - it's a regression against a decision made before I started implementing this. The design write-up I did for this feature explicitly flagged pointer-bit-stealing (the Folly `PackedSyncPtr` technique) as unusable for libc++ specifically because it assumes 48-bit VA and breaks on LA57 5-level paging and ARMv8.2 LVA/52-bit VA, and recommended a hazard-pointer fallback instead for exactly that reason. That got lost somewhere between the design phase and the implementation commit (866b4403), and I didn't catch the regression myself - thanks for catching it.
I'll fix the design so it doesn't assume a fixed VA width. Since you clearly know this space: is there a reliable way to detect at compile time whether a target's VA can exceed what fits in the spare pointer bits?

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