正确实现futex互斥锁需先用原子CAS抢锁，失败后才FUTEX_WAIT；unlock时须先原子置0再FUTEX_WAKE 1；锁变量用std::atomic声明，初始值为0，配对使用FUTEX_WAIT/FUTEX_WAKE并注意ABI差异与信号安全。
futex系统调用的正确初始化与唤醒语义
直接用futex写互斥锁，第一步不是加锁，而是理解FUTEX_WAIT和FUTEX_WAKE的配对逻辑：它们操作的是用户态内存地址上的整数值，但内核只在值“符合预期”时才真正挂起或唤醒线程。比如FUTEX_WAIT会先原子检查该地址值是否等于传入的val，只有相等才休眠；否则立刻返回-EAGAIN。
- 必须用
std::atomic<int></int>（或volatile int+ 显式内存序）声明锁变量，避免编译器重排或缓存不一致 - 初始值必须是
0（表示未上锁），非零值（如1）才表示已上锁——这个约定要和所有futex操作保持一致 -
FUTEX_WAKE的nr参数填1即可，唤醒一个等待者足够；填INT_MAX反而可能误唤醒无关线程
手写futex_mutex::lock()的原子检查与忙等退避
纯futex锁不能一上来就FUTEX_WAIT，得先用CAS抢锁；失败后才进入等待路径。否则多个线程同时FUTEX_WAIT在同一个地址，但锁值早已被别人改掉，会导致“虚假唤醒”或永久挂起。
- 用
__atomic_compare_exchange_n(&m_val, &expected, 1, false, __ATOMIC_ACQUIRE, __ATOMIC_RELAX)尝试获取锁，expected初始为0 - 失败时，需循环检查：
if (__atomic_load_n(&m_val, __ATOMIC_ACQUIRE) == 0) goto retry;—— 避免在值已变回0时还去wait - 真正调用
syscall(SYS_futex, &m_val, FUTEX_WAIT, 1, nullptr, nullptr, 0)前，确保m_val仍为1，且自己是唯一等待者
示例关键片段：
int expected = 0;
while (!__atomic_compare_exchange_n(&m_val, &expected, 1, false,
__ATOMIC_ACQUIRE, __ATOMIC_RELAX)) {
if (expected == 0) continue; // 别人释放了，重试
syscall(SYS_futex, &m_val, FUTEX_WAIT, 1, nullptr, nullptr, 0);
expected = 0;
}
futex_mutex::unlock()必须配对FUTEX_WAKE且避免惊群
unlock()看似简单，但漏掉FUTEX_WAKE或唤醒条件错，就会导致等待线程永远卡住。更隐蔽的问题是：如果unlock()时没人等待，FUTEX_WAKE无害；但如果有人正执行到FUTEX_WAIT前的检查阶段，就可能错过唤醒。
立即学习“C++免费学习笔记（深入）”；
- 必须用
__atomic_store_n(&m_val, 0, __ATOMIC_RELEASE)清零锁值，保证其他线程能看到 - 紧接着调用
syscall(SYS_futex, &m_val, FUTEX_WAKE, 1, nullptr, nullptr, 0)，不能省略 - 不要用
FUTEX_WAKE_OP或复杂变体——它引入额外内存操作，且glibc的futex封装本身就有竞态窗口 - 注意：Linux 2.6.22+ 支持
FUTEX_PRIVATE_FLAG，若锁仅用于同一进程内线程，加上它能绕过进程间futex哈希查找，性能更好
实际使用中容易被忽略的ABI与调试陷阱
你写的futex锁在GCC下跑通，换Clang或不同内核版本可能行为突变。根本原因是syscall(SYS_futex, ...)参数顺序、结构体填充、甚至errno设置方式在不同libc实现里不统一。
- 务必用
linux/futex.h里的宏定义（如FUTEX_WAIT），别手写数字0或1 - 调试时用
strace -e trace=futex ./your_program确认系统调用是否真的发出，以及返回值是否为0（成功）或-1（失败并设errno） - 在容器或musl libc环境里，
SYS_futex可能不可用，需fallback到syscall(__NR_futex, ...)并检查__NR_futex宏是否存在 - 不要在信号处理函数里调用你的futex锁——
FUTEX_WAIT可被信号中断，返回-EINTR，而你的代码未必处理它
最麻烦的从来不是怎么写对，而是怎么让别人（包括三个月后的你自己）相信它在线程切换、信号、内核调度边界下依然可靠。每次修改都要跑带超时的死锁压力测试，而不是只验证单线程逻辑。
