C++笔记之不同线程访问同一资源时，读操作、写操作对锁的要求一样吗？
code review!
文章目录
- C++笔记之不同线程访问同一资源时，读操作、写操作对锁的要求一样吗？
- 1. 核心结论：读写操作的锁要求本质不同
- 2. 方案一：传统独占锁（std::mutex）
- 3. 方案二：读写锁（std::shared_mutex，C++17）
- 3.1 代码示例
- 4. 特殊情况：纯只读数据完全不需要锁
- 4.1 前提一：初始化时的"发布"过程必须正确同步
- 4.2 前提二：确认操作确实是"纯读"，没有隐藏的写
- 5. 总结
1. 核心结论：读写操作的锁要求本质不同
在C++中，多线程访问共享资源时，读操作和写操作对锁的要求是不对称的，并非"一刀切"。
这种不对称性的根源在于C++对数据竞争（Data Race）的定义：同一内存位置上的并发访问，只要不是"两者都是读"，且至少一个访问不是原子操作、缺乏适当同步，就构成未定义行为。换句话说：
- 读是安全的：多个线程同时读取数据不会改变数据本身，天然不会引发数据竞争。
- 写是破坏性的：只要有一个线程在写，其他线程无论是读还是写，都可能导致未定义行为。
具体到并发场景，可以归纳为：
| 场景 | 是否需要互斥 |
|---|---|
| 写 vs 写 | 需要 |
| 写 vs 读 | 需要 |
| 读 vs 读 | 通常不需要，可以并发 |
正是基于这种不对称性，C++提供了不同层次的锁策略，从"完全平等对待读写"到"区分读写并发能力"，逐步演进。
2. 方案一：传统独占锁（std::mutex）
如果使用最基础的s