std::mutex无法解决跨进程资源竞争，因其仅限单进程内线程间同步；跨进程需用posix信号量、共享内存中的pthread_mutex_t（带pthread_process_shared）、文件锁等机制。
进程间资源争抢不是 std::mutex 能解决的问题——它只在单个进程内的线程间有效。你要防的是**跨进程**的资源竞争，比如多个独立运行的 C++ 程序同时写同一个文件、读同一块共享内存、或操作同一个硬件设备。
为什么 std::mutex 对多进程完全无效
std::mutex 是基于线程本地状态（如 futex 或内核等待队列）实现的，其生命周期绑定在进程地址空间内。两个不同进程的 std::mutex 实例互不可见，加锁操作彼此无感知，形同虚设。
- 即使你把
std::mutex放在mmap映射的共享内存里，也不能直接用——它没做跨进程初始化，内部字段（如 owner tid）是进程私有的 - 试图对同一块共享内存中的
std::mutex调用lock()，行为未定义，大概率 crash 或静默失效 - 所有 RAII 锁类（
std::lock_guard、std::unique_lock）都继承这一限制
真正可用的跨进程同步原语
POSIX 和 Windows 提供了专为进程间设计的同步机制，C++ 标准库不封装它们，需直接调用系统 API 或用封装库（如 Boost.Interprocess）：
-
pthread_mutex_t配合PTHREAD_PROCESS_SHARED属性：可在mmap共享内存中初始化，支持多进程互斥 -
sem_open()/sem_wait()/sem_post()：命名信号量，通过名字（如"/mydb_lock"）全局可见，无需共享内存即可协调 - 文件锁（
flock()或fcntl(F_SETLK)）：轻量，适合保护配置文件、日志文件等，但注意 NFS 兼容性差 - 本地 socket 或 Unix domain socket：可用于传递锁状态或实现简单的仲裁服务（例如“谁先连上 server.sock 就获得资源”）
常见误用：把 std::mutex 放进 shared_memory_object
Boost.Interprocess 的 shared_memory_object 常被误认为能“让 std::mutex 跨进程工作”。事实是：
- 你可以把
boost::interprocess::interprocess_mutex（非std::mutex！）放进共享内存，它专为此设计 - 但
std::mutex即使放在同一块mmap区域，也无法安全使用——它的 ABI 和初始化逻辑不满足进程共享要求 - 错误示例：
new (shared_ptr) std::mutex()→ 未定义行为，某些平台可能看似运行，但随时死锁或崩溃
最易被忽略的一点：跨进程锁必须显式销毁（如 sem_unlink()、shm_unlink()），否则残留的锁文件或信号量会阻塞后续启动；而线程锁随进程退出自动清理。这个差异导致很多“测试时正常、上线后卡死”的问题。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
