c++oding="utf-8" ?>
std::shared_mutex在读多写少场景下存在写者饥饿、延迟突增等问题，因其通用等待队列缺乏reader批量唤醒优化；手写reader-preferring锁需用原子计数+条件变量，注意伪共享、内存序与唤醒策略。
为什么不能直接用 std::shared_mutex？
在 C++17 及以上，std::shared_mutex 确实提供了读写分离语义，但它的默认实现（尤其在 libstdc++ 和 libc++ 中）对“读多写少”场景并不友好：写者饥饿风险高、读锁释放时可能触发不必要的内核调度、且不保证 reader 优先或 writer 优先策略。实际压测中，当读者线程数 > 20 且写操作每秒数次时，std::shared_mutex 的平均读延迟可能突增 3–5 倍——这不是锁粒度问题，而是其内部使用了通用等待队列，未做 reader 批量唤醒优化。
用原子计数 + 条件变量手写 reader-preferring 锁的关键点
核心思路是：用一个 std::atomic<int></int> 记录当前活跃读者数，再用一个 std::mutex 保护写者独占状态和等待队列。写者必须等所有当前读者退出、且无新读者能进入后才执行；而读者只要发现无活跃写者，就可立即进入。
-
读者入口要双重检查：先原子递增 reader 计数，再检查是否有写者正在等待（用另一个
std::atomic<bool></bool>write_pending），若有则立即回退并阻塞在条件变量上 - 写者必须先标记 pending，再等 reader 归零：否则可能被新读者“插队”，导致写饥饿
- reader 退出时不唤醒写者：只在最后一个 reader 退出时，才 notify_one 写者条件变量；避免惊群
-
别用
std::condition_variable::wait直接传 lambda：某些旧版标准库在 lambda 捕获中持有锁时有竞态，建议显式 while 循环 +cv.wait(lock, []{...})
一个轻量但生产可用的实现骨架
class rw_lock {
std::atomic<int> reader_count{0};
std::atomic<bool> write_pending{false};
std::mutex write_mutex;
std::condition_variable read_cv;
std::condition_variable write_cv;
public:
void lock_shared() {
reader_count.fetch_add(1, std::memory_order_acquire);
std::unique_lock<:mutex> lk(write_mutex);
read_cv.wait(lk, [this]{ return !write_pending.load(std::memory_order_acquire); });
}
void unlock_shared() {
if (reader_count.fetch_sub(1, std::memory_order_release) == 1) {
// 最后一个 reader，唤醒等待的 writer
write_cv.notify_one();
}
}
void lock() {
std::unique_lock<:mutex> lk(write_mutex);
write_pending.store(true, std::memory_order_release);
write_cv.wait(lk, [this]{ return reader_count.load(std::memory_order_acquire) == 0; });
}
void unlock() {
write_pending.store(false, std::memory_order_release);
read_cv.notify_all(); // 允许所有阻塞 reader 继续
}
};
</:mutex></:mutex></bool></int>
注意：lock_shared() 中的 fetch_add 必须在检查 write_pending 前完成，否则可能漏掉刚设为 true 的写请求；unlock() 里用 notify_all() 是因为多个 reader 可能同时被 pending 阻塞，但只需唤醒一次——后续 reader 会自己检查 write_pending 并决定是否等待。
性能敏感时必须避开的坑
这个实现看似简单，但在高并发下容易因 cache line 伪共享拖慢：如果 reader_count 和 write_pending 在同一 cache line，读者频繁的 fetch_add 会让写者所在的 CPU 不断失效该 line，造成显著抖动。
- 把两个原子变量用
alignas(64)分开，确保不共用 cache line - 不要在
lock_shared()里加额外日志或函数调用——哪怕只是std::chrono::now()，都可能让热点路径变慢 20% - 如果写操作极少（比如配置热更新），可考虑去掉
write_cv，改用自旋 +std::this_thread::yield()等待 reader 归零（仅限单 socket 场景） - Windows 上慎用
SlimReaderWriterLock的 SRWLock API：它在非 NT 内核兼容层下，AcquireSRWLockShared可能退化为临界区，失去读并发性
真正难的不是写对，而是让 reader_count 的原子操作不成为瓶颈——这需要看具体 CPU 架构和 NUMA 布局，没有银弹。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
