4 ms·

https://www.cppstories.com/2026/shared_mutex/#newer-concurrency-tools-in-c20-and-above https://www.cppstories.com/2026/shared_mutex/#newer-concurre... > Since

by loeg 8mo ago

https://www.cppstories.com/2026/shared_mutex/#newer-concurrency-tools-in-c20-and-above 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.)

surajrmal 8mo ago
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.
- loeg 8mo ago
  This is true, but it is a subset of designs using shared_mutex.
- secondcoming 8mo ago
  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.
- foldr 8mo ago
  Not an expert, but can’t you get synchronization like this just by using release/acquire memory order with C11 atomic stores and loads?
  - jeffbee 8mo ago
    Yes. But if you are tempted to do this in most cases you should just use a mutex anyway.
  - jpc0 8mo ago
    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.

by loeg 8mo ago

surajrmal 8mo ago

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.

loeg 8mo ago
This is true, but it is a subset of designs using shared_mutex.
secondcoming 8mo ago
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.
foldr 8mo ago
Not an expert, but can’t you get synchronization like this just by using release/acquire memory order with C11 atomic stores and loads?
- jeffbee 8mo ago
  Yes. But if you are tempted to do this in most cases you should just use a mutex anyway.
- jpc0 8mo ago
  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.