因为std::atomic_flag仅支持单布尔状态，无法编码“读中/写中/空闲”三态及读者计数，强行使用会导致阻塞、饿死或ABA问题；需改用std::atomic<int>以高位表写锁、低位表读者数，并配合适当内存序与yield机制。
为什么不能直接用 std::atomic_flag 实现读写自旋锁
因为 std::atomic_flag 只支持单个布尔状态，无法区分「读中」「写中」「无访问」三种状态，更没法计数当前有多少读者。硬塞进去会导致读者被阻塞、写者饿死，或者出现 ABA 问题——比如两个读者交替加减，中间写者插不进来。
真正可行的起点是 std::atomic<int></int>：用一个整数编码状态，高位表示是否被写者占用（如最高位为 1 表示写锁定），低位存读者数量（如低 31 位）。但要注意 x86-64 上 int 是 32 位，std::atomic<int></int> 的 CAS 操作是原子的，只要不溢出（读者数 ≤ 2³¹−1）就安全。
- 写者尝试获取锁时，期望值是 0，用
compare_exchange_strong原子设为 -1（即全 1 的补码，高位为 1） - 读者加锁时，先读当前值，若非负且未被写者占用，再 CAS 尝试 +1；失败则重试
- 读者解锁时，只做原子减 1，无需 CAS（只要没溢出，减法本身不会破坏状态）
手写 rw_spinlock 的核心状态机逻辑
关键不是“怎么加锁”，而是“怎么避免写者无限等待”。必须让写者在发现读者活跃时主动 yield，否则会拖垮其他线程。典型做法是在 CAS 失败后插入 std::this_thread::yield() 或 _mm_pause()（x86）。
下面是一个最小可用实现的关键片段：
立即学习“C++免费学习笔记（深入）”；
class rw_spinlock {
std::atomic<int> state_{0};
public:
void lock_read() {
int expected;
do {
expected = state_.load(std::memory_order_acquire);
if (expected < 0) { // 写者已占
std::this_thread::yield();
continue;
}
} while (!state_.compare_exchange_weak(expected, expected + 1,
std::memory_order_acquire, std::memory_order_relaxed));
}
void lock_write() {
int expected = 0;
while (!state_.compare_exchange_weak(expected, -1,
std::memory_order_acquire, std::memory_order_relaxed)) {
if (expected < 0) {
std::this_thread::yield(); // 写者竞争
} else if (expected > 0) {
std::this_thread::yield(); // 读者正活跃
}
expected = 0; // 重试前重置期望值
}
}
void unlock_read() {
state_.fetch_sub(1, std::memory_order_release);
}
void unlock_write() {
state_.store(0, std::memory_order_release);
}
};
注意 unlock_write() 必须用 store 而非 fetch_add，否则可能把读者数清零；而 unlock_read() 用 fetch_sub 是安全的，因为只有读者能改这个值。
内存序选 acquire/release 而非 seq_cst 的原因
读写锁的核心约束只有两条：1）写者临界区对其他线程可见；2）读者进入前必须看到写者已退出。这完全可以用 acquire（进锁）+ release（出锁）满足，不需要全局顺序一致的 seq_cst ——后者在 ARM/AArch64 上开销显著更高，x86 虽然硬件强序，但编译器仍可能插入多余屏障。
-
lock_read()用acquire：确保后续读操作不被重排到锁之前 -
unlock_read()用release：确保此前读操作不被重排到锁之后 -
lock_write()的 CAS 成功路径需要acquire，失败路径不用 -
unlock_write()的store必须是release，否则读者可能看到“旧写结果”
实际使用时最容易忽略的三个点
第一，没有写者公平性机制。当前实现下，新来的写者永远排在读者后面，如果读者持续不断（比如高频监控线程），写者可能饿死。解决办法是加一个等待写者计数器，或改用 ticket-based 设计，但这会增加状态大小和 CAS 复杂度。
第二，lock_read() 中的 load 和 compare_exchange_weak 之间存在时间窗口：若此时写者刚好 acquire 成功，读者仍可能 CAS +1 成功，导致状态变成 -1+1=0 ——这是严重 bug。修复方式是把读操作改为「先尝试读状态，若为 0 则直接 CAS -1，否则再走读者路径」，或者统一用三态枚举 + std::atomic<uint32_t> 编码。
第三，别在中断上下文或实时线程里用它。自旋锁不放弃 CPU，一旦争抢激烈，会抬高系统整体延迟，且无法被信号打断。真要低延迟，得换带 futex 等待的用户态读写锁，或者直接用内核提供的 pthread_rwlock_t。
