使用std::atomic时，无需原子性场景下能否用构造函数替代store()优化？

Great question—let’s break this down from both the strict C++ standard perspective and real-world practicality, since those two often intersect in tricky ways with atomics.

1. Strict C++ Standard Perspective #

First, let’s clarify what your proposed replacement is doing: you’re using placement new to construct a new std::atomic<node*> instance directly over the memory occupied by an existing one, instead of calling store(nullptr, std::memory_order_relaxed) on the existing atomic object. From the standard’s view, this is problematic unless you meet very narrow conditions:

• Object Lifecycle Rules: If the original std::atomic<node*> at p hasn’t been explicitly destroyed (via p.~atomic<node*>()), using placement new here ends the old object’s lifecycle and starts a new one. If any other thread is still accessing the old object while this happens, that’s immediate undefined behavior (UB)—the standard forbids accessing an object after its lifecycle has ended.
• Constructor Atomicity: Unlike store() (even with memory_order_relaxed), the constructor of std::atomic<T> is not an atomic operation. The standard explicitly states that atomic constructors (other than the default constructor, which leaves the object uninitialized) do not provide atomicity or synchronization. If another thread could read or write to the memory at p while the constructor runs, you have a data race—another form of UB that the C++ memory model strictly prohibits.
• Initialization Guarantees: While store(relaxed) guarantees that the write to nullptr is atomic (even if it doesn’t enforce ordering with other operations), the constructor’s write to the underlying pointer is just a regular non-atomic store as far as the standard is concerned. No atomicity guarantees apply here.

2. Real-World Practicality #

Now, let’s say you’re in a scenario where you know for sure no other thread is accessing the memory at p (so the "no atomicity needed" condition is fully satisfied). What happens then?

• Compiler Implementation Behavior: For most mainstream compilers (GCC, Clang, MSVC), constructing a std::atomic<node*> with nullptr via placement new will generate nearly identical machine code to store(nullptr, std::memory_order_relaxed). Under the hood, atomic pointer types are just raw pointers with special synchronization semantics for operations like store/load—their constructors for pointer values typically just perform a plain write to memory, no extra overhead.
• Readability & Maintainability: This is the bigger practical issue. Using store() makes your intent crystal clear: you’re updating the value of an existing atomic variable. Using placement new, by contrast, reads like you’re reinitializing the atomic object itself, which can confuse other developers (or even your future self) about the code’s purpose. It’s a clever trick with no meaningful performance gain, but a big hit to maintainability.
• Hidden Risks: Even if you think no threads are accessing p, edge cases (like a stray pointer in another thread, or a race condition you missed) can turn this "safe" optimization into a silent UB bug that’s nearly impossible to debug.

3. Final Takeaway #

• From a strict规范 perspective: You can only safely replace store(relaxed) with placement new if:
  • You’ve explicitly destroyed the original std::atomic object at p first, and
  • No other thread will access the memory at p during the constructor call.
    Without both conditions, you’re playing with undefined behavior.
• From a practical perspective: Don’t do it. std::memory_order_relaxed is already the lightest-weight atomic operation available—its overhead is negligible, often identical to a plain non-atomic write. The tiny (if any) performance gain isn’t worth the loss of readability, maintainability, and the risk of introducing hard-to-track bugs.

Stick with p.store(nullptr, std::memory_order_relaxed)—it’s explicit, correct, and communicates your intent clearly to everyone who reads the code.

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