信号量死锁需通过gdb中thread apply all bt查看线程是否卡在sem_wait、sem_timedwait或std::counting_semaphore::acquire，再结合thread N切换逐个分析栈帧中的持有与等待关系，人工比对交叉依赖链来定位。
信号冲突在 gdb 里根本不会报错，它只是死锁——线程卡在 sem_wait 或 acquire 上，CPU 占用率低，程序不动。你得靠堆栈和线程状态反推。
怎么确认是信号量导致的死锁
运行卡住后，在 gdb 中执行 thread apply all bt，重点看哪些线程停在：
-
sem_wait、sem_timedwait（POSIX 信号量） -
std::counting_semaphore::acquire（C++20） -
pthread_mutex_lock（如果误把互斥量当信号量用）
如果多个线程分别卡在不同信号量的 acquire 上，且调用栈显示它们正按相反顺序尝试获取 A/B，基本就是信号量获取顺序不一致引发的循环等待。
为什么 info threads 看不出问题，但 thread <n></n> 切过去就关键
info threads 只显示线程 ID 和状态（Running/Blocked），不告诉你它在等谁；真正要定位冲突，必须逐个切换：
立即学习“C++免费学习笔记（深入）”；
- 用
thread 2切到某一线程 - 再用
bt看完整调用栈，确认它已持有哪些信号量（比如刚调过sem_post或release）、正阻塞在哪次acquire - 对比其他线程的持有/等待关系：比如线程 2 持有
sem_A等sem_B，线程 3 持有sem_B等sem_A
这种交叉依赖无法靠单条命令发现，必须人工比对多个线程的 bt 输出。
C++20 std::counting_semaphore 的调试陷阱
它没有超时机制，一旦卡死，gdb 里只能看到线程停在 acquire，但没法知道“等了多久”或“要不要放弃”。相比而言：
- POSIX 的
sem_timedwait可设abs_timeout，gdb 里能看到系统调用参数，便于判断是否真卡死还是只是慢 - 若你用的是
std::counting_semaphore，建议在开发期加一层 wrapper，用std::chrono::steady_clock::now()打日志，记录 acquire 开始时间——否则 gdb 里完全没上下文 - 不要在 RAII 对象析构里抛异常，否则
~scoped_semaphore中的release可能被跳过，导致信号量永久泄漏
最容易被忽略的释放遗漏点
不是所有 acquire 都配了 release，尤其在以下场景：
- 函数中间有
return，但release写在末尾 - 调用了可能 throw 的函数（如
std::vector::at越界），而release在 catch 外面 - 用裸指针传递
sem_t*，某个分支忘了传进来的信号量该由谁 release
RAII 封装不是可选项——是唯一能兜底的方案。手写 acquire/release 对，等于默认接受“某次异常路径下信号量永远卡死”的风险。
