代码单步如何与线程一起工作?
我正在使用 Visual Studio 2010 开发 C++。如何设计代码单步来处理新线程的创建?
如果我单步执行代码并使用 CreateThread() 生成一个新线程,我会进入该线程吗?如果没有,为什么不呢?
编辑: 即使在线程函数中设置断点,我也会得到不可预测的结果。有时我的程序在遇到线程函数中的断点之前退出。我只是想知道是什么导致了这种行为。
I'm developing C++ with Visual Studio 2010. How is code stepping designed to deal with creation of new threads?
If I am stepping through code and I spawn a new thread with CreateThread()
, will I enter that thread? If not, why not?
Edit:
I am getting unpredictable results, even with breakpoints in the thread function. Sometimes my program exits before hitting a breakpoint in the thread function. I am just wondering about what gives rise to this behavior.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这取决于。
如果在单步执行调用
CreateThread
的代码时,CreateThread
调用的方法遇到断点,那么调试器将切换到该断点和线程。从那时起(直到再次按 F5)执行单步指令 (F10) 时,偶尔会在原始线程和 CreateThread 创建的线程之间交替。对于在给定中断会话期间创建的每个线程都是如此。一旦你按下 F5 并再次中断(通过断点或暂停),一切都会重置,并且单步执行只会单步执行最初中断的线程。
这是一个示例应用程序
如果我在
_tmain
中的printf
函数上放置一个断点,按下 F5,然后在击中断点后使用 F10 单步执行,我将永远不会单步执行Thread2
方法。但是,如果我在
_tmain
和Thread2
的入口点上放置断点,然后按 F5,情况就会发生变化。首先,我将按预期命入_tmain
中的断点。如果此后我继续按 F10,我最终将到达 Thread2 中的断点。从那时起,我可以继续按 F10,它将在两个线程之间交替每隔几步。注意:这并不是因为我一直命中断点。这两个断点仅被命中一次,因为它们位于方法入口点。这只是调试器行为,在调试器中为给定停止而显式中断的线程之间进行交替。
This depends.
If the method called by
CreateThread
ever hits a breakpoint while you are stepping through the code that calledCreateThread
then the debugger will switch to that breakpoint and thread. From then on (until you hit F5 again) doing step over instructions (F10) will occasionally alternate between the original thread and the one created byCreateThread
.This is true for every thread which is created during a given break session. Once you hit F5 though and break again (via breakpoint or pause) everything resets and stepping will only step through the thread which was originally broken into.
Here's an example app
If I put a breakpoint on the
printf
function in_tmain
hit F5 and then use F10 to step after the breakpoint is hit I will never step into theThread2
method.However if I put a breakpoint on both the entry point to
_tmain
andThread2
and then hit F5 things change. First I will hit the breakpoint in_tmain
as expected. If I keep hitting F10 after that I will eventually hit the breakpoint inThread2
. From then on I can keep hitting F10 and it will alternate between the two threads ever few steps.Note: This is not because I keep hitting the breakpoints. Both of the breakpoints are hit only once since they're at the method entry point. It's simply the debugger behavior to alternate between threads which have been explicitly broken into for a given stop in the debugger.
不,我不这么认为。您将继续当前线程,直到在另一个线程中命中断点。
No I do not think so. You will continue on the current thread until a breakpoint is hit in the other thread.
执行将在当前线程中继续,直到遇到断点。该断点可以位于单独的线程中,并且执行将在该线程中遵循相同的规则继续。
The execution will continue in the current thread until a breakpoint is hit. This breakpoint can be in a separate thread and execution will continue in that thread following the same rule.
不,您没有直接调用线程方法(这会破坏线程的目的)。您请求运行时与当前线程并行执行您的线程函数,并尽快启动。
如果您没有在所有线程中预定义断点,当您选择“step over”时,我已经看到 MS 调试器在线程之间来回跳动,但我不能说我可以判断它是否有任何可预测性。
No, you are not calling your thread method directly (that would defeat the purpose of the thread). You are requesting that the runtime execute your thread function in parallel with the current thread, starting as soon as possible.
If you don't have predefined breakpoints in all threads, I have seen MS debuggers bounce back and forth between threads when you choose "step over", but I can't say that I can tell if there is any predictability to it.
不,单步执行意味着您正在单步执行特定线程的执行上下文。调试器有多种方法来切换您正在查看的线程。有一个“线程”窗口,其中显示有关进程中所有线程的信息。您还可以在新线程的入口点设置断点。
因为调试器不知道CreateThread是一个启动新线程的特殊函数。它只知道您已要求它跳过函数调用,因此它假设您希望保留在当前线程中。此外,根据调度,新线程可能会也可能不会立即启动。例如,您可以在暂停状态下启动新线程。
No, single stepping means you're stepping through the execution context of a particular thread. The debugger has several ways to switch which thread you're viewing. There's a Threads window which shows you information about all of the threads in the process. You could also set a breakpoint at the entry point for the new thread.
Because the debugger doesn't know that CreateThread is a special function that launches a new thread. It just knows that you've asked it to step over the function call, and so it assumes you want to remain in the current thread. Also, depending on the scheduling, the new thread may or may not start right away. You could, for example, start the new thread in a paused state.