Comment by loeg | Hacker News Reader

Comment by loeg | Hacker News Reader

https://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.

This is true, but it is a subset of designs using shared_mutex.

I think it's possible with an atomic<shared_ptr> too (C++20)?

A shared_mutex comes in useful when you can't really have multiple copies of the shared data due to perhaps memory usage, so readers fail to acquire it when the writer is updating it.

Not an expert, but can’t you get synchronization like this just by using release/acquire memory order with C11 atomic stores and loads?

Yes. But if you are tempted to do this in most cases you should just use a mutex anyway.

From my knowledge RCU/epoch/Hazard pointers are useful in data structures and algorithms where raw atomics cannot be used but you still nees lock free or in some cases wait free semantics.

If you can use an atomic then these are overkill and you should just be using an atomic, but many times things that are atomic does not make it lock free, if there's no hardware support the compiler will add a mutex.

Reply on news.ycombinator.com