Windows SuspendThread 没有？ (GetThreadContext 失败)

Question

我们有一个 Windows32 应用程序，其中一个线程可以停止另一个线程来检查它的通过执行 SuspendThread/GetThreadContext/ResumeThread 状态 [PC 等]。

if (SuspendThread((HANDLE)hComputeThread[threadId])<0)  // freeze thread
   ThreadOperationFault("SuspendThread","InterruptGranule");
CONTEXT Context, *pContext;
Context.ContextFlags = (CONTEXT_INTEGER | CONTEXT_CONTROL);
if (!GetThreadContext((HANDLE)hComputeThread[threadId],&Context))
   ThreadOperationFault("GetThreadContext","InterruptGranule");

在极少数情况下，在多核系统上，GetThreadContext 返回错误代码 5(Windows 系统错误代码“拒绝访问”)。

SuspendThread 文档似乎清楚地表明目标线程已挂起，如果没有返回错误。我们正在检查SuspendThread和ResumeThread的返回状态；他们从不提示。

为什么我可以挂起一个线程，但不能访问它的上下文呢？

这个博客 http://www.dcl.hpi.uni-potsdam.de/research/WRK/2009/01/what-does-suspendthread-really-do/

表明 SuspendThread 在返回时可能已经开始暂停另一个线程，但该线程尚未暂停。在这种情况下，我可以看出 GetThreadContext 会有什么问题，但这似乎是一种定义 SuspendThread 的愚蠢方法。 (SuspendThread 的调用如何知道目标线程何时真正挂起？)

编辑:我撒谎了。我说这是针对 Windows 的。

好吧，奇怪的是我在 Windows XP 64 下没有看到这种行为(至少在上周没有，我真的不知道在那之前发生了什么)......但我们一直在测试这个Ubuntu 10.x 上 Wine 下的 Windows 应用程序。 Wine source for the guts of GetThreadContext包含当由于某种原因尝试获取线程状态失败时，第 819 行的访问被拒绝返回响应。我在猜测，但 Wine GetThreadStatus 似乎认为线程可能无法重复访问。为什么在 SuspendThead 之后那会是真的我无法理解，但是有代码。想法？

EDIT2:我又撒谎了。我说我们只看到了 Wine 上的行为。不……我们现在发现了一个 Vista Ultimate 系统似乎会产生同样的错误(同样，很少)。因此，Wine 和 Windows 似乎就一个模糊的案例达成了一致。似乎仅启用 Sysinternals Process 监控程序会使情况恶化并导致问题出现在 Windows XP 64 上；我怀疑是 Heisenbug。 (进程监视器甚至在我用于开发的 Wine-tasting (:-) 机器或 XP 64 系统上都不存在)。

这到底是什么？

EDIT3:2010 年 9 月 15 日。我在不干扰 SuspendThread、ResumeThread 和 GetContext 的代码的情况下，对错误返回状态进行了仔细检查。自从我那样做以来，我还没有在 Windows 系统上看到这种行为的任何提示。还没有回到 Wine 实验。

2010 年 11 月:奇怪。似乎如果我在 VisualStudio 2005 下编译它，它在 Windows Vista 和 7 上会失败，但在更早的操作系统上不会。如果我在 VisualStudio 2010 下编译，它不会在任何地方失败。有人可能会指责 VisualStudio2005，但我怀疑存在位置敏感问题，VS 2005 和 VS 2010 中的不同优化器将代码放置在略有不同的位置。

2012 年 11 月:Saga 继续。我们在许多 XP 和 Windows 7 机器上看到这种故障，故障率非常低(每几千次运行一次)。我们的 Suspend 事件应用于主要执行纯计算代码但有时会调用 Windows 的线程。当线程的 PC 在我们的计算代码中时，我不记得看到过这个问题。当然，我看不到线程挂起时的PC，因为GetContext不会给我，所以我不能直接确认问题只发生在执行系统调用的时候。但是，我们所有的系统调用都是通过一个点进行的，到目前为止，证据表明当我们挂起时那个点就被执行了。因此，间接证据表明，只有在该线程正在执行系统调用时，线程上的 GetContext 才会失败。我还没有精力建立一个关键实验来检验这个假设。

Answer 1

让我引用 Richter/Nassare 的“Windows via C++ 5Ed”，这可能会说明一些问题:

DWORD SuspendThread(HANDLE hThread);

Any thread can call this function to suspend another thread (as long as you have the thread's handle). It goes without saying (but I'll say it anyway) that a thread can suspend itself but cannot resume itself. Like ResumeThread, SuspendThread returns the thread's previous suspend count. A thread can be suspended as many as MAXIMUM_SUSPEND_COUNT times (defined as 127 in WinNT.h). Note that SuspendThread is asynchronous with respect to kernel-mode execution, but user-mode execution does not occur until the thread is resumed.

In real life, an application must be careful when it calls SuspendThread because you have no idea what the thread might be doing when you attempt to suspend it. If the thread is attempting to allocate memory from a heap, for example, the thread will have a lock on the heap. As other threads attempt to access the heap, their execution will be halted until the first thread is resumed. SuspendThread is safe only if you know exactly what the target thread is (or might be doing) and you take extreme measures to avoid problems or deadlocks caused by suspending the thread.

...

Windows actually lets you look inside a thread's kernel object and grab its current set of CPU registers. To do this, you simply call GetThreadContext:

BOOL GetThreadContext( HANDLE hThread, PCONTEXT pContext);

To call this function, just allocate a CONTEXT structure, initialize some flags (the structure's ContextFlags member) indicating which registers you want to get back, and pass the address of the structure to GetThreadContext. The function then fills in the members you've requested.

You should call SuspendThread before calling GetThreadContext; otherwise, the thread might be scheduled and the thread's context might be different from what you get back. A thread actually has two contexts: user mode and kernel mode. GetThreadContext can return only the user-mode context of a thread. If you call SuspendThread to stop a thread but that thread is currently executing in kernel mode, its user-mode context is stable even though SuspendThread hasn't actually suspended the thread yet. But the thread cannot execute any more user-mode code until it is resumed, so you can safely consider the thread suspended and GetThreadContext will work.

我的猜测是，如果您只是调用 SuspendThread，GetThreadContext 可能会失败，而线程处于内核模式，此时内核正在锁定线程上下文 block 。

也许在多核系统上，一个内核正在处理线程的内核模式执行，它的用户模式刚刚被挂起，保持锁定线程的 CONTEXT 结构，恰好在另一个内核调用 GetThreadContext 时。

由于没有记录此行为，我建议联系 Microsoft。