为何std::atomic_ref<std::shared_ptr<T>>不可用？C++20原子访问疑问

1. 混合原子与无同步访问的安全性 #

无论C++20前后，混合原子操作和非原子操作访问同一个std::shared_ptr<T>对象都是未定义行为。

C标准明确规定：如果一个对象被任何原子操作（包括C20前的std::atomic_load等函数，或C++20的std::atomic<std::shared_ptr<T>>特化）访问，那么所有对该对象的读写操作都必须是原子的。非原子的方法调用（比如直接ptr.get()）会绕过原子同步机制，导致数据竞争，触发未定义行为。

C++20只是把原子操作的接口从自由函数换成了std::atomic的特化，但核心的内存模型规则没有变化。

2. std::atomic_ref<std::shared_ptr<T>>不可用的原因 #

std::atomic_ref的模板参数要求T是平凡可复制类型（trivially copyable），而std::shared_ptr<T>显然不满足这一条件：它的复制构造/赋值涉及控制块引用计数的修改，不是简单的内存字节拷贝。

标准没有为std::shared_ptr<T>提供atomic_ref的特化，因为atomic_ref的设计目标是适配可以通过原始内存操作完成原子访问的类型，而shared_ptr的状态维护（双指针+引用计数）无法通过这种方式实现原子操作。

3. 原子操作的效率问题与优化方向 #

确实，std::atomic<std::shared_ptr<T>>的原子加载操作会返回一个副本，必然会增加控制块的引用计数——这是保证返回的shared_ptr持有有效所有权的必要代价，避免原对象被其他线程修改后导致悬空指针。

如果想在某些场景下降低开销，可以考虑：

• 明确内存顺序：在不需要强同步的场景下，使用std::memory_order_relaxed或std::memory_order_acquire（而非默认的std::memory_order_seq_cst），减少内存栅栏的开销，但引用计数的修改仍然不可避免。
• 拆分访问需求：如果只是需要读取指向的数据而不需要持有所有权，可以考虑额外维护一个原子指针（比如std::atomic<T*>），但这需要自己管理生命周期，风险较高，仅适用于数据对象不会被销毁、或有其他同步机制保证生命周期的特定场景。
• 避免不必要的原子访问：如果能保证某段代码中没有其他线程访问该shared_ptr，可以通过load()获取副本后，在单线程环境下操作副本，但原原子对象的所有访问仍需保持原子性。

内容的提问来源于stack exchange，提问作者Fedor