std::binary_semaphore是C++20轻量信号同步原语，仅支持0/1状态，需编译器（GCC 11+/Clang 13+/MSVC 16.11+）启用-std=c++20及线程库，适用于事件通知等简单场景，不保护临界区且析构时存在未定义行为。
std::binary_semaphore 是 C++20 的同步原语，但不是所有编译器默认启用
它在 <semaphore> 头文件中定义，依赖于 C++20 标准和底层操作系统支持（如 Linux futex、Windows WaitOnAddress）。GCC 11+ 和 Clang 13+ 支持，但需显式开启 -std=c++20，且 GCC 默认不启用 std::binary_semaphore（需配合 -pthread 和 libc++/libstdc++ 的完整 C++20 同步支持）。MSVC 2019 16.11+ 可用，但早期版本会静默退化为自旋或抛 std::system_error。
常见错误现象：error: 'binary_semaphore' is not a member of 'std' 或链接时报 undefined reference to 'sem_wait' —— 这通常是因为标准库未实现或未链接线程库。
- 确认编译命令含
-std=c++20 -pthread（Linux/macOS）或/std:c++20 /EHsc（MSVC） - 检查
__cpp_lib_semaphore >= 201907L宏是否定义（可用#ifdefguard） - 避免在单线程构建或 freestanding 环境中使用
std::binary_semaphore 的典型用法：初始化、acquire、release
它只允许两种状态：0 或 1，本质是“可重入的互斥锁”（但不绑定线程所有权），适合资源有无控制，比如控制一个共享缓冲区是否就绪、通知某个事件已发生。
关键点：构造时传入初始计数值（通常为 0 或 1），acquire() 阻塞直到值 > 0 并原子减 1；release() 原子加 1（可唤醒一个等待线程）；try_acquire() 非阻塞尝试。
立即学习“C++免费学习笔记（深入）”；
#include <semaphore>
#include <thread>
#include <iostream>
std::binary_semaphore sem{0}; // 初始不可用
void waiter() {
sem.acquire(); // 阻塞，直到 release 被调用
std::cout << "Got signal!\n";
}
void signaler() {
std::this_thread::sleep_for(1s);
sem.release(); // 唤醒一个 acquire 中的线程
}
int main() {
std::thread t1(waiter);
std::thread t2(signaler);
t1.join(); t2.join();
}
- 不能重复
acquire()多次而不release()—— 第二次会永久阻塞（因值卡在 0） -
release()可被任意线程调用，不限于acquire()的线程 - 没有超时版
acquire()（C++20 不提供），如需限时请改用std::counting_semaphore<1>+ 条件变量或平台 API
与 std::mutex / std::condition_variable 对比：何时该选 binary_semaphore
它比 std::mutex 更轻量（无所有权、无递归、无异常安全要求），也比 std::condition_variable 更直接（无需配套 mutex 和谓词判断）。但代价是语义更窄 —— 它只表达“一个信号”，不携带数据或状态描述。
- 适合场景：线程启动同步（如主线程等 worker 初始化完成）、I/O 就绪通知、pipeline 中 stage 间简单握手
- 不适合场景：保护临界区（用
std::mutex）、等待复杂条件（如 “队列非空且 size > 5”）、需要公平调度或多等待者广播（std::condition_variable::notify_all()更合适） - 性能差异：在支持 futex 的系统上，
std::binary_semaphore常常是纯用户态操作，无系统调用开销；而std::mutex在争用时可能陷入内核
容易被忽略的生命周期和异常安全细节
std::binary_semaphore 析构时若仍有线程在 acquire() 中等待，行为是未定义的（通常程序 abort 或死锁）。它也不提供移动或复制操作 —— 必须确保对象生存期覆盖所有可能的 acquire() 调用。
- 不要在局部作用域声明后交给其他线程长期使用（例如返回栈上
binary_semaphore的引用） - 避免在析构函数中调用
acquire()或release()—— 析构顺序不确定，易导致访问已销毁对象 - 它不保证异常安全：
acquire()可能抛std::system_error（如资源不足），但不会因中断或超时抛出（因无超时）
实际项目中，如果需要跨模块传递信号语义，建议包装一层 RAII 类并明确文档化其生命周期约束 —— 底层原语本身不做任何保护。
