Linux下必须用sem_open()创建命名信号量实现跨进程同步，因std::counting_semaphore仅限单进程线程使用且不可跨进程共享，误用sem_init()或共享内存包装均会导致同步失效。
Linux下用POSIX命名信号量实现跨进程同步
标准C++不提供跨进程信号量，必须依赖操作系统API。在Linux上，sem_open()创建的命名信号量（named semaphore）是唯一能被多个独立进程通过名字访问的方案，它不依赖共享内存或fork关系。
常见错误是误用sem_init()——它只适用于同一进程内的线程，且需配合共享内存使用；若在不同进程中各自调用sem_init()，每个进程操作的是自己内存里的副本，完全无法同步。
- 必须用
sem_open("/mysem", O_CREAT, 0644, 1)，名字以/开头，长度不能超过NAME_MAX-4（通常251字节） - 创建后需检查返回值是否为
SEM_FAILED，并用perror()查看具体错误（如Permission denied常因umask或SELinux导致） - 进程退出前必须调用
sem_close()；彻底删除信号量要用sem_unlink("/mysem")，否则残留会阻塞后续运行
Windows上用CreateSemaphoreW替代方案
Windows没有POSIX信号量，对应机制是命名内核对象CreateSemaphoreW()。它的行为和POSIX命名信号量高度一致，但API风格完全不同，且名字区分大小写、支持反斜杠路径格式。
容易忽略的关键点：Windows信号量初始计数必须≥0，且最大值不能超过LONG_MAX；若传入负数或超限，函数直接返回NULL，GetLastError()返回ERROR_INVALID_PARAMETER。
立即学习“C++免费学习笔记（深入）”；
- 创建示例：
CreateSemaphoreW(NULL, 1, 1, L"MySem")，第三个参数是最大计数值，不是当前值 - 跨进程访问时，所有进程必须用完全相同的宽字符串名字，且确保调用方有SE_CREATE_GLOBAL_NAME权限（服务进程默认无）
- 关闭句柄用
CloseHandle()，但不会自动销毁对象；要彻底清理得用ReleaseSemaphore()配合计数归零逻辑，或依赖系统在最后一个句柄关闭时自动回收
为什么std::semaphore和std::counting_semaphore不适用
C++20引入的std::counting_semaphore是纯用户态、无内核支撑的同步原语，底层基于std::atomic实现，仅限单进程内多线程使用。它无法被其他进程映射或识别。
试图把std::counting_semaphore变量放在mmap共享内存里也不行——其内部状态含非POD成员（如std::atomic的对齐约束和可能的锁实现），跨进程读写会导致未定义行为，常见表现为死锁或计数错乱。
- 编译器不会报错，但运行时行为不可预测；glibc和MSVC的
std::counting_semaphore均未声明为trivially_copyable - 即便手动用
sem_wait()/sem_post()包装，也无法绕过其设计初衷：它是为线程同步优化的，没有跨进程标识机制
调试信号量状态的实用技巧
信号量本身不提供查询接口，出问题时很难直接看到当前值。Linux下可用ls -l /dev/shm/确认命名信号量是否存在（POSIX信号量挂载在此），但无法读取计数值；Windows下可用Process Explorer搜索“Semaphore”对象名定位句柄归属。
真正有效的做法是在代码中加入日志+原子计数器模拟：
// Linux示例：记录每次wait/post前后的预期值
static std::atomic_int debug_count{1};
void safe_wait(sem_t* s) {
std::cout << "before wait: " << debug_count.load() << "\n";
sem_wait(s);
debug_count--;
std::cout << "after wait: " << debug_count.load() << "\n";
}
这种模拟不改变实际同步逻辑，但能快速暴露逻辑错误，比如某进程反复wait却无人post，或计数变为负值。
跨进程同步里最麻烦的不是API调用，而是生命周期管理——信号量对象比任意一个使用者都活得久，又必须比所有使用者都死得晚。稍不注意，就变成一个进程在sem_open()时发现信号量已被删，另一个进程在sem_post()时触发SIGSEGV。
