The more general idea for this is readers-writer lock: https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock

> 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.)

It happens with locking APIs, it happens with socket APIs, anything platform dependent.

Does the C++ standard give you an idiomatic way to set PTHREAD_RWLOCK_PREFER_READER_NP or PTHREAD_RWLOCK_PREFER_WRITER_NP explicitly when initializing a rwlock? Nope. Then you either roll your own or in Rust you reach for a crate where someone did the work of making a smarter primitive for you.