alt Hacker Newshttps://www.cppstories.com/2026/shared_mutex/#newer-concurre...
> Since C++17, the concurrency library has expanded significantly. We now have:
> ...
> safe memory reclamation mechanisms (RCU, hazard pointers in C++26)
> These tools focus mostly on thread lifetime, coordination, cancellation or lock-free programming.
> std::shared_mutex fills a different role.
> It is still a mutual-exclusion primitive, explicitly designed to protect a shared state with many readers and few writers. It does not compete with atomics, condition variables, or RCU.
What does it mean to say shared_mutex does not "compete" with atomics/CVs/RCU? There are many situations where RCU or other safe reclamation mechanism is a good replacement for state + shared_mutex. (And some situations where atomics are a decent replacement.)
If you want the write to be a synchronization point after which all threads will observe only the new value, it's only possible with shared mutex. Of course you can use a barrier to accomplish that instead but using something like hazard pointers or rcu doesn't synchronize by itself.