pthread_mutex_t 必须位于进程间共享内存中才能实现跨进程互斥，仅设置PTHREAD_PROCESS_SHARED属性无效；正确做法是通过shm_open+mmap分配共享内存，并在其中初始化mutex，且需用pthread_mutexattr_setpshared显式配置属性。
pthread_mutex_t 必须放在共享内存里，不能在栈或堆上分配
进程间互斥量不是“配个属性就跨进程”，核心前提是：pthread_mutex_t 实例本身得被多个进程映射到同一物理内存页。如果用 new pthread_mutex_t 或局部变量定义，每个进程都有自己的副本，PTHREAD_PROCESS_SHARED 属性根本没意义——锁状态不共享，自然无法互斥。
常见错误写法：
pthread_mutex_t mtx; // ❌ 全局变量？仍属进程私有地址空间<br>pthread_mutex_init(&mtx, &attr); // 即使 attr 设了 PTHREAD_PROCESS_SHARED，也无效
正确做法是：用 shm_open + mmap 分配共享内存，再把 pthread_mutex_t 放进去（比如作为结构体成员）。
- 共享内存大小至少为
sizeof(SharedData)，其中SharedData包含pthread_mutex_t字段 - 映射时必须用
MAP_SHARED，不能用MAP_PRIVATE - 所有进程都需调用
mmap映射同一 shm 文件描述符，才能看到同一个mtx地址
pthread_mutexattr_setpshared 是必需步骤，且不能漏掉 init
PTHREAD_PROCESS_SHARED 不是默认行为，必须显式设置。只调用 pthread_mutex_init(&mtx, nullptr) 会得到进程私有互斥量，即使它在共享内存里——内核根本不认。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
完整初始化流程（仅由第一个进程执行）：
pthread_mutexattr_t attr;<br>pthread_mutexattr_init(&attr); // ❗ 必须先 init，否则未定义行为<br>pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED); // ❗ 关键一步<br>pthread_mutex_init(mtx_ptr_in_shm, &attr); // mtx_ptr_in_shm 指向共享内存中的 mutex 字段<br>pthread_mutexattr_destroy(&attr);
- 若忘记
pthread_mutexattr_init，attr是未初始化的垃圾值，setpshared可能静默失败 - 多个进程竞争首次初始化时，需用原子标志（如
__atomic_load_n(&init_flag, __ATOMIC_ACQUIRE)）避免重复 init，否则pthread_mutex_init被多次调用会 UB - Windows 下无此机制，别试图移植这套代码
不要混用 std::shared_mutex 或 std::mutex
std::shared_mutex 和 std::mutex 在跨进程场景下完全不可用。它们底层依赖线程 ID、TLS 或进程内指针，跨进程后线程 ID 无效、地址空间隔离、状态无法同步——不是“加不上锁”，而是会触发未定义行为：可能看似正常运行数小时后突然死锁，或静默损坏共享数据。
- 强行把
std::shared_mutex放进 mmap 区域？编译可能过，运行必崩 - 用
boost::interprocess::named_mutex？它封装了sem_open或CreateMutexW，但异常路径下易残留信号量，sem_unlink忘删会导致后续进程卡死在sem_wait - 真正可选的只有三类：POSIX
sem_open、WindowsCreateSemaphoreExW、或mmap + pthread_mutex_t + PTHREAD_PROCESS_SHARED
首次初始化者必须唯一，且要处理竞态
两个进程几乎同时启动，都尝试初始化共享内存里的互斥量，结果只有一个能成功——另一个调用 pthread_mutex_init 会返回 EBUSY 或直接 UB。没有内置的“原子初始化”机制，得自己协调。
推荐做法（轻量级）：
- 在共享内存头部设一个
int init_flag，初始为 0 - 进程启动后，用
__atomic_compare_exchange_n(&init_flag, &expected, 1, false, __ATOMIC_ACQ_REL, __ATOMIC_ACQUIRE)尝试置 1 - 仅当交换成功（即本进程是第一个），才调用
pthread_mutex_init - 其他进程轮询等待，直到
__atomic_load_n(&init_flag, __ATOMIC_ACQUIRE) == 1再使用该锁
这步最容易被跳过，导致多进程反复尝试初始化同一块内存，最终锁状态混乱。别指望“谁先 mmap 谁先 init”——时间差在纳秒级，竞争必然发生。
