gdb无法实现所有线程同步停在同一个断点；thread apply all b仅设同名断点，各线程独立触发；需用set scheduler-locking on控制调度、catch syscall futex捕获同步原语，或改代码插入barrier等显式同步点。
gdb 中 thread apply all break 不能让所有线程“同步停在同一个断点”
很多人误以为用 thread apply all b func_name 就能让所有线程一到 func_name 就暂停——其实这只是给每个线程都设了同名断点，各线程仍按各自执行流独立触发，根本不同步。真正想实现“所有活跃线程都运行到某行再一起停住”，gdb 本身没有原生的“全局同步断点”机制。
用 set scheduler-locking on 配合单步控制主线程，间接约束其他线程
这是最实用、也最可控的做法：先停在目标函数入口（比如 pthread_create 返回后或临界区前），然后开启调度锁定，再单步执行，让主线程推进时其他线程不被调度——但这只影响“新调度”，已运行中的线程仍可能继续跑。所以关键在于：必须在所有线程都尚未进入目标区域时就介入。
-
set scheduler-locking on后，next/step只会让当前线程单步，其他线程挂起（不保证已阻塞的线程立刻冻结，但能阻止新时间片分配） - 适合场景：你刚启动程序，所有工作线程还在初始化或等待信号，此时在
main里设断点，开锁，再用continue放行到线程创建完成，再切到目标线程用thread <n></n>切换，再设断点 - 注意：
set scheduler-locking step更严格（连当前线程单步时也锁死其他线程），但某些系统调用（如read）可能绕过，导致意外唤醒
用 catch syscall futex 捕获线程同步原语，定位竞争起点
如果你真正关心的是“多个线程何时同时抵达某个临界区入口”，与其强求它们停在同一行，不如抓它们实际同步行为的信号。Linux 下 pthread_mutex / condition variable / barrier 底层大多走 futex 系统调用。
-
catch syscall futex可捕获所有线程对 futex 的等待/唤醒操作，配合thread <n></n>和info threads能看出谁卡在哪次等待 - 加条件断点更精准：
catch syscall futex if $rdi == 0x12345678（假设你已知 mutex 内部地址） - 缺点：futex 调用频繁，容易误触发；需用
info proc mappings查内存布局，确认地址有效性
用 pthread_cond_wait 或 std::barrier 主动插入同步点，再调试
最可靠的方式其实是改代码——在你想观察的逻辑前插入显式同步机制，让所有线程自愿等齐，这时再下断点，100% 同步停住。
- C++20：
static inline std::barrier sync_point{num_threads};，每线程执行sync_point.arrive_and_wait();，全部到达后才继续 - POSIX：
pthread_barrier_t+pthread_barrier_wait()，注意初始化和销毁生命周期 - 调试时，在
arrive_and_wait()后第一行设断点，所有线程必然在此处暂停，且状态一致 - 上线前删掉或用宏包裹，不影响生产行为
真正难的不是让 gdb 停住，而是确认“所有线程此刻是否真的处于你认为的同一逻辑状态”。寄希望于 gdb 自动同步，往往掩盖了对线程调度本质的理解偏差。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
