与 GDB 非步进执行相比，GDB 步进 Linux 上的线程调度行为
Thread scheduling behavior on Linux between steps with GDB compared to non-stepped execution with GDB
GDB 手册指出，当使用 all-stop 模式调试多线程应用程序时，不可能使每个线程在锁步中仅通过一条语句前进。这是有道理的，因为 GDB 中的一个步骤本质上允许所有线程由 OS 调度（但是 OS 决定这样做）直到调用该步骤的线程到达下一个语句.
我的问题是：假设 GDB 步骤之间 OS 的平均调度行为与不步进时 OS 的平均调度行为相当是否合理（虽然仍然使用 GDB 来保持尽可能多的变量不变），或者步进是否足以影响调度，以至于线程的推进（平均而言）与没有步进的情况不同？
如果步进确实影响了行为，我如何才能在我的程序中的离散点获得多线程程序流和程序状态的准确表示？录制和回放是否可行？
Is it reasonable to assume that the average scheduling behavior of the OS in between GDB steps is comparable to the average scheduling behavior of the OS when not stepping
不是真的。 "not stepping" 平均行为将使线程 运行 超出其时间份额，或阻塞系统调用。在 "stepping" 的情况下，线程不太可能每个 运行 超出它们的时间份额（因为步骤之间的时间距离可能非常短）。所以 平均 行为可能非常不同。
how can I get an accurate representation of multithreaded program flow and program state at discrete points in my program?
一般来说，你不应该关心多线程程序流程。这样调试多线程程序是不可能的。
在进行多线程编程时，您必须注意保留不变量（每个可以被多个线程访问的资源都受到保护，以防止数据竞争等）。如果你这样做，你的程序就会正常工作（TM）。如果不这样做，您就不太可能找到 所有 程序异常行为的方式。
GDB 手册指出，当使用 all-stop 模式调试多线程应用程序时，不可能使每个线程在锁步中仅通过一条语句前进。这是有道理的，因为 GDB 中的一个步骤本质上允许所有线程由 OS 调度（但是 OS 决定这样做）直到调用该步骤的线程到达下一个语句.
我的问题是：假设 GDB 步骤之间 OS 的平均调度行为与不步进时 OS 的平均调度行为相当是否合理（虽然仍然使用 GDB 来保持尽可能多的变量不变），或者步进是否足以影响调度，以至于线程的推进（平均而言）与没有步进的情况不同？
如果步进确实影响了行为，我如何才能在我的程序中的离散点获得多线程程序流和程序状态的准确表示？录制和回放是否可行？
Is it reasonable to assume that the average scheduling behavior of the OS in between GDB steps is comparable to the average scheduling behavior of the OS when not stepping
不是真的。 "not stepping" 平均行为将使线程 运行 超出其时间份额，或阻塞系统调用。在 "stepping" 的情况下，线程不太可能每个 运行 超出它们的时间份额（因为步骤之间的时间距离可能非常短）。所以 平均 行为可能非常不同。
how can I get an accurate representation of multithreaded program flow and program state at discrete points in my program?
一般来说，你不应该关心多线程程序流程。这样调试多线程程序是不可能的。
在进行多线程编程时，您必须注意保留不变量（每个可以被多个线程访问的资源都受到保护，以防止数据竞争等）。如果你这样做，你的程序就会正常工作（TM）。如果不这样做，您就不太可能找到 所有 程序异常行为的方式。