【翻译】【多线程】SuspendThread到底是如何把线程暂停住的？

0xAA55

原文网址：https://www.dcl.hpi.uni-potsdam. ... ndthread-really-do/
作者：Martin von Löwis
（作者名字音译：马丁·凡·路易斯）
感谢原作者对此做出的努力。
Thanks to Martin, we got the answers.

最近，包括我在内的很多人，问了我一个问题：当你调用SuspendThread的时候，它是立即将线程暂停住，还是得让线程运行一段时间后才能被暂停住？（同样的问题也有TerminateThread是否立即将线程干掉等，答案和现在的话题差不多）

在单线程系统下我们可以说SuspendThread会立即把指定线程暂停住：至少要被暂停的那个线程（如果不是当前线程）此时肯定没有在运行。但是在多处理器（多核、多线程）的情况下，事情就会变得没那么简单，首先线程就有可能在不同的处理器中运行——那么，我们得花多久才能把别的线程暂停住，并且，当SuspendThread返回的时候，目标线程真的已经被暂停了吗？

让我们看一下NtSuspendThread的代码（在psspnd.c里面）首先它检查要被暂停的线程是不是当前线程，然后立即调用KeSuspendThread。如果是其它线程，它首先取得Thread->RundownProtect，来防止这个正在被操作的线程被删除。KiSuspendThread （在thredobj.c）检查Thread->SuspendCount的值来判断它是否超出了MAXIMUM_SUSPEND_COUNT的值，超出的话报错退出（STATUS_SUSPEND_COUNT_EXCEEDED）。否则，它用以下的代码来暂停目标线程：

02179     //
02180     // Don't suspend the thread if APC queuing is disabled. In this case the
02181     // thread is being deleted.
02182     //
02183
02184     if (Thread->ApcQueueable == TRUE) {
02185
02186         //
02187         // Increment the suspend count. If the thread was not previously
02188         // suspended, then queue the thread's suspend APC.
02189         //
02190         // N.B. The APC MUST be queued using the internal interface so
02191         //      the system argument fields of the APC do not get written.
02192         //
02193
02194         Thread->SuspendCount += 1;
02195         if ((OldCount == 0) && (Thread->FreezeCount == 0)) {
02196             if (Thread->SuspendApc.Inserted == TRUE) {
02197                 KiLockDispatcherDatabaseAtSynchLevel();
02198                 Thread->SuspendSemaphore.Header.SignalState -= 1;
02199                 KiUnlockDispatcherDatabaseFromSynchLevel();
02200
02201             } else {
02202                 Thread->SuspendApc.Inserted = TRUE;
02203                 KiInsertQueueApc(&Thread->SuspendApc, RESUME_INCREMENT);
02204             }
02205         }
02206     }

当它完成的时候，它直接就返回了（并且在返回之前把之前入口处取得的调度数据库释放了）。

正要被暂停的线程在这里只是被SuspendThread安排了一个用来暂停它的“异步处理调用”（APC），它并没有真正的直接去暂停目标线程。通常，我们可以预料到APC会在下一次系统调度线程的时候被调用；此时线程已经在一个不同的处理器上运行了，然后它就进入了暂停的状态。

但让我们再进一步观察，Thread->SuspendApc的值是多少？它被KeInitThread用以下的代码初始化：

00178     //
00179     // Initialize the kernel mode suspend APC and the suspend semaphore object.
00180     // and the builtin wait timeout timer object.
00181     //
00182
00183     KeInitializeApc(&Thread->SuspendApc,
00184                     Thread,
00185                     OriginalApcEnvironment,
00186                     (PKKERNEL_ROUTINE)KiSuspendNop,
00187                     (PKRUNDOWN_ROUTINE)KiSuspendRundown,
00188                     KiSuspendThread,
00189                     KernelMode,
00190                     NULL);
00191
00192     KeInitializeSemaphore(&Thread->SuspendSemaphore, 0L, 2L);

于是这里注册了这个APC的三个功能：内核过程KiSuspendNop（它啥也不做），KiSuspendRundown（如果线程在APC运行之前终止，则清除APC），KiSuspendThread，这个负责实际的暂停操作，它是这样定义的：

01667 {
01668
01669     PKTHREAD Thread;
01670
01671     UNREFERENCED_PARAMETER(NormalContext);
01672     UNREFERENCED_PARAMETER(SystemArgument1);
01673     UNREFERENCED_PARAMETER(SystemArgument2);
01674
01675     //
01676     // Get the address of the current thread object and Wait nonalertable on
01677     // the thread's builtin suspend semaphore.
01678     //
01679
01680     Thread = KeGetCurrentThread();
01681     KeWaitForSingleObject(&Thread->SuspendSemaphore,
01682                           Suspended,
01683                           KernelMode,
01684                           FALSE,
01685                           NULL);
01686
01687     return;
01688 }

所以这个基本上就是在遇到暂停信号后不返回了，直到收到了继续信号。为了支持多重交织的SuspendThread的调用，它用了一个计数器，所以第一次调用SuspendThread会把暂停信号安排到APC，而最后一次ResumeThread则会吧继续信号发过去。
回到主题，我们的问题是：它是立即暂停，还是只有在APC得到处理后才会暂停？KiInsertQueueApc首先做了一件我们能理解的事情：插入APC到线程的APC队列。然而，然后它运行的代码看起来是想让APC立即运行。它是这样开始的：

00489     // If the APC index from the APC object matches the APC Index of
00490     // the thread, then check to determine if the APC should interrupt
00491     // thread execution or sequence the thread out of a wait state.
00492     //
00493
00494     if (Apc->ApcStateIndex == Thread->ApcStateIndex) {

什么是“APC state index”（APC状态索引），它的值到底是多少？我并不真的知道；对于APC，它应该是OriginalApcEnvironment。这也应该是目标线程的ApcStateIndex的值（所以这种情况通常是对的），但我并没有搞懂APC环境的概念（也找不到任何能说得过去的解释）。
任何情况，假定条件为True，它就会去检测我们是否给当前线程安排了APC，如果有这个APC，它就立即执行一个APC_LEVEL软中断。否则（比如给别的线程安排APC），我们就锁定调度数据库，从RequestInterrupt=FALSE开始，执行下面的这一段复杂的代码：


00531         if (ApcMode == KernelMode) {
00532
00533             //
00534             // Thread transitions from the standby state to the running
00535             // state can occur from the idle thread without holding the
00536             // dispatcher lock. Reading the thread state after setting
00537             // the kernel APC pending flag prevents the code from not
00538             // delivering the APC interrupt in this case.
00539             //
00540             // N.B. Transitions from gate wait to running are synchronized
00541             //      using the thread lock. Transitions from running to gate
00542             //      wait are synchronized using the APC queue lock.
00543             //
00544             // N.B. If the target thread is found to be in the running state,
00545             //      then the APC interrupt request can be safely deferred to
00546             //      after the dispatcher lock is released even if the thread
00547             //      were to be switched to another processor, i.e., the APC
00548             //      would be delivered by the context switch code.
00549             //
00550
00551             Thread->ApcState.KernelApcPending = TRUE;
00552             KeMemoryBarrier();
00553             ThreadState = Thread->State;
00554             if (ThreadState == Running) {
00555                 RequestInterrupt = TRUE;
00556
00557             } else if ((ThreadState == Waiting) &&
00558                        (Thread->WaitIrql == 0) &&
00559                        (Thread->SpecialApcDisable == 0) &&
00560                        ((Apc->NormalRoutine == NULL) ||
00561                         ((Thread->KernelApcDisable == 0) &&
00562                          (Thread->ApcState.KernelApcInProgress == FALSE)))) {
00563
00564                 KiUnwaitThread(Thread, STATUS_KERNEL_APC, Increment);
00565
00566             } else if (Thread->State == GateWait) {
00567                 KiAcquireThreadLock(Thread);
00568                 if ((Thread->State == GateWait) &&
00569                     (Thread->WaitIrql == 0) &&
00570                     (Thread->SpecialApcDisable == 0) &&
00571                     ((Apc->NormalRoutine == NULL) ||
00572                      ((Thread->KernelApcDisable == 0) &&
00573                       (Thread->ApcState.KernelApcInProgress == FALSE)))) {
00574
00575                     GateObject = Thread->GateObject;
00576                     KiAcquireKobjectLock(GateObject);
00577                     RemoveEntryList(&Thread->WaitBlock[0].WaitListEntry);
00578                     KiReleaseKobjectLock(GateObject);
00579                     if ((Queue = Thread->Queue) != NULL) {
00580                         Queue->CurrentCount += 1;
00581                     }
00582
00583                     Thread->WaitStatus = STATUS_KERNEL_APC;
00584                     KiInsertDeferredReadyList(Thread);
00585                 }
00586
00587                 KiReleaseThreadLock(Thread);
00588             }
00589
00590         } else if ((Thread->State == Waiting) &&
00591                   (Thread->WaitMode == UserMode) &&
00592                   (Thread->Alertable || Thread->ApcState.UserApcPending)) {
00593
00594             Thread->ApcState.UserApcPending = TRUE;
00595             KiUnwaitThread(Thread, STATUS_USER_APC, Increment);
00596         }

所以让我们来分析一下状况：

• ApcMode == Kernel? 是，暂停线程的APC是作为一个内核APC创建的。
• ThreadState == Running? 仅当这个线程在另一个处理器上运行的时候，是这样。此时我们把RequestInterrupt设为true。
• ThreadState == Waiting? 如果要暂停的线程已经卡在WaitForSingleObject的时候是这样。
• ThreadState == GateWait? 不知道这是啥。
• Thread->SpecialApcDisable==0? 看起来平时一般都应该是这样，至少线程一般都允许有这样的APC产生。
• Apc->NormalRoutine == NULL? 并不，我们有一个NormalRoutine（就是KiSuspendThread）
• 其他情况 (WaitIrql, KernelApcDisable, KernelApcInProgress)? 如果目标线程此时正在内核的临界区做点什么的话这些应该是false。
  

所以如果目标线程在内核模式运行的话，它还是要继续运行一下的；如果它卡住了，它会醒来执行一下它的APC。
然后它释放调度锁，并且运行下面的代码：

00604         if (RequestInterrupt == TRUE) {
00605             KiRequestApcInterrupt(Thread->NextProcessor);
00606         }

KiRequestApcInterrupt接下来会检测它是不是在同一个处理器上（我们的情况是它可以不在同一个处理器上），然后发送一个APC_LEVEL的“处理器间中断”到线程所在的处理器（通过KiIpiSend来发送，KiIpiSend调用了HAL）。这将会让目标处理器进入内核模式，然后找到这个APC并处理它。

所以总而言之：

• 如果目标线程卡在了内核模式，它会先执行完内核模式的代码，然后在回到用户模式之前，它处理APC队列的时候，线程就暂停了。
• 如果目标线程在另一个处理器上，一个IPI会把它中断，此时它就暂停了。
  

在这两种情况，SuspendThread会在目标线程真的暂停之前就立即返回了——因为它并没有专门去等这个线程中断了才会返回，因为线程仍然需要处理其APC队列，或者另一种情况就是它发出了IPI，但并不等待中断处理，就立即返回了。
2009.1.19

0xAA55

所以SuspendThread()并不是用来进行线程管理的，不然非常容易造成临界区死锁。它只是在调试的时候，你不得不把一个线程停住的时候才用上的。而自己对自己的程序进行多线程调度管理的时候，是不应该用这个函数来暂停自己的线程的——用Sleep()、SwitchToThread()、WaitForSingleObject()或者WaitForMultipleObjects()才是正确的选择。

MSDN上的内容：
This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization. Calling SuspendThread on a thread that owns a synchronization object, such as a mutex or critical section, can lead to a deadlock if the calling thread tries to obtain a synchronization object owned by a suspended thread. To avoid this situation, a thread within an application that is not a debugger should signal the other thread to suspend itself. The target thread must be designed to watch for this signal and respond appropriately.

参考资料：
https://blogs.msdn.microsoft.com/oldnewthing/20150205-00/?p=44743

唐凌

简单说，就是SuspendThread这个函数通过插入APC的方式命令指定线程等待Semaphore
话说von是德国人和匈牙利人特有的名字，就像荷兰人特有van一样，前者是“冯”，后者是“范”
比如冯诺依曼：von Neumann
再比如范佩西：van Persie

QQ小冰

老湿！我想知道这个源代码是从哪里来的？是自己逆向的还是微软公开的？

0xAA55

tangptr@126.com 发表于 2017-2-21 00:18
简单说，就是SuspendThread这个函数通过插入APC的方式命令指定线程等待Semaphore
话说von是德国人和匈牙利 ...

我以为是法国人的，所以翻译了个“凡”