内核同步对象
来源：互联网 发布：淘宝上的紫砂壶能买吗 编辑：程序博客网 时间：2024/05/16 05:19
内核同步对象（上）
Windows NT提供了五种内核同步对象(Kernel Dispatcher Object)，你可以用它们控制非任意线程(普通线程)的流程。表4-1列出了这些内核同步对象的类型及它们的用途。在任何时刻，任何对象都处于两种状态中的一种：信号态或非信号态。有时，当代码运行在某个线程的上下文中时，它可以阻塞这个线程的执行，调用KeWaitForSingleObject或KeWaitForMultipleObjects函数可以使代码(以及背景线程)在一个或多个同步对象上等待，等待它们进入信号态。内核为初始化和控制这些对象的状态提供了例程。
表4-1. 内核同步对象
在下几段中，我将描述如何使用内核同步对象。我将从何时可以调用等待原语阻塞线程开始讲起，然后讨论用于每种对象的支持例程。最后讨论与线程警惕(thread alert)和提交APC(异步过程调用)相关的概念。
何时阻塞和怎样阻塞一个线程
为了理解WDM驱动程序何时以及如何利用内核同步对象阻塞一个线程，你必须先对线程有一些基本了解。通常，如果在线程执行时发生了软件或硬件中断，那么在内核处理中断期间，该线程仍然是“当前”线程。而内核模式代码执行时所在的上下文环境就是指这个“当前”线程的上下文。为了响应各种中断，Windows NT调度器可能会切换线程，这样，另一个线程将成为新的“当前”线程。
术语“任意线程上下文(arbitrary thread context)”和“非任意线程上下文(nonarbitrary thread context)”用于精确描述驱动程序例程执行时所处于的上下文种类。如果我们知道程序正处于初始化I/O请求线程的上下文中，则该上下文不是任意上下文。然而，在大部分时间里，WDM驱动程序无法知道这个事实，因为控制哪个线程应该激活的机会通常都是在中断发生时。当应用程序发出I/O请求时，将产生一个从用户模式到内核模式的转换，而创建并发送该IRP的I/O管理器例程将继续运行在非任意线程的上下文中。我们用术语“最高级驱动程序”来描述第一个收到该IRP的驱动程序。
通常，只有给定设备的最高级驱动程序才能确切地知道它执行在一个非任意线程的上下文中。这是因为驱动程序派遣例程通常把请求放入队列后立即返回调用者。之后通过回调函数，请求被提出队列并下传到低级驱动程序。一旦派遣例程挂起某个请求，所有对该请求的后期处理必须发生在任意线程上下文中。
解释完线程上下文后，我们可以陈诉出关于线程阻塞的简单规则：
当我们处理某个请求时，仅能阻塞产生该请求的线程。
通常，仅有设备的最高级驱动程序才能应用这个规则。但有一个重要的例外，IRP_MN_START_DEVICE请求，所有驱动程序都以同步方式处理这个请求。即驱动程序不排队或挂起该类请求。当你收到这种请求时，你可以直接从堆栈中找到请求的发起者。正如我在第六章中讲到的，处理这种请求时你必须阻塞那个线程。
下面规则表明在提升的IRQL级上不可能发生线程切换：
执行在高于或等于DISPATCH_LEVEL级上的代码不能阻塞线程。
这个规则表明你只能在DriverEntry函数、AddDevice函数，或驱动程序的派遣函数中阻塞当前线程。因为这些函数都执行在PASSIVE_LEVEL级上。没有必要在DriverEntry或AddDevice函数中阻塞当前线程，因为这些函数的工作仅仅是初始化一些数据结构。
在单同步对象上等待
你可以按下面方法调用KeWaitForSingleObject函数：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LARGE_INTEGER timeout;NTSTATUS status = KeWaitForSingleObject(object, WaitReason, WaitMode, Alertable, &timeout);ASSERT语句指出必须在低于或等于DISPATCH_LEVEL级上调用该例程。
在这个调用中，object指向你要等待的对象。注意该参数的类型是PVOID，它应该指向一个表4-1中列出的同步对象。该对象必须在非分页内存中，例如，在设备扩展中或其它从非分页内存池中分配的数据区。在大部分情况下，执行堆栈可以被认为是非分页的。
WaitReason是一个纯粹建议性的值，它是KWAIT_REASON枚举类型。实际上，除非你指定了WrQueue参数，否则任何内核代码都不关心此值。线程阻塞的原因被保存到一个不透明的数据结构中，如果你了解这个数据结构，那么在调试某种死锁时，你也许会从这个原因代码中获得一些线索。通常，驱动程序应把该参数指定为Executive，代表无原因。
WaitMode是MODE枚举类型，该枚举类型仅有两个值：KernelMode和UserMode。
Alertable是一个布尔类型的值。它不同于WaitReason，这个参数以另一种方式影响系统行为，它决定等待是否可以提前终止以提交一个APC。如果等待发生在用户模式中，那么内存管理器就可以把线程的内核模式堆栈换出。如果驱动程序以自动变量(在堆栈中)形式创建事件对象，并且某个线程又在提升的IRQL级上调用了KeSetEvent，而此时该事件对象刚好又被换出内存，结果将产生一个bug check。所以我们应该总把alertable参数指定为FALSE，即在内核模式中等待。
最后一个参数&timeout是一个64位超时值的地址，单位为100纳秒。正数的超时表示一个从1601年1月1日起的绝对时间。调用KeQuerySystemTime函数可以获得当前系统时间。负数代表相对于当前时间的时间间隔。如果你指定了绝对超时，那么系统时钟的改变也将影响到你的超时时间。如果系统时间越过你指定的绝对时间，那么永远都不会超时。相反，如果你指定相对超时，那么你经过的超时时间将不受系统时钟改变的影响。
指定0超时将使KeWaitForSingleObject函数立即返回，返回的状态代码指出对象是否处于信号态。如果你的代码执行在DISPATCH_LEVEL级上，则必须指定0超时，因为在这个IRQL上不允许阻塞。每个内核同步对象都提供一组KeReadStateXxx服务函数，使用这些函数可以直接获得对象的状态。然而，取对象状态与0超时等待不完全等价：当KeWaitForSingleObject发现等待被满足后，它执行特殊对象要求的附加动作。相比之下，取对象状态不执行任何附加动作，即使对象已经处于信号态。
超时参数也可以指定为NULL指针，这代表无限期等待。
该函数的返回值指出几种可能的结果。STATUS_SUCCESS结果是你所希望的，表示等待被满足。即在你调用KeWaitForSingleObject时，对象或者已经进入信号态，或者后来进入信号态。如果等待以第二种情况满足，则有必要在同步对象上执行附加动作。当然，这个附加动作还要参考对象的类型，我将在后面讨论具体对象类型时再解释这一点。(例如，一个同步类型的事件在你的等待满足后需要重置该事件)
返回值STATUS_TIMEOUT指出在指定的超时期限内对象未进入信号态。如果指定0超时，则函数将立即返回。返回代码为STATUS_TIMEOUT，代表对象处于非信号态，返回代码为STATUS_SUCCESS，代表对象处于信号态。如果指定NULL超时，则不可能有返回值。
其它两个返回值STATUS_ALERTED和STATUS_USER_APC表示等待提前终止，对象未进入信号态。原因是线程接收到一个警惕(alert)或一个用户模式的APC。
在多同步对象上等待
KeWaitForMultipleObjects函数用于同时等待一个或多个同步对象。该函数调用方式如下：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LARGE_INTEGER timeout;NTSTATUS status = KeWaitForMultipleObjects(count, objects, WaitType, WaitReason, WaitMode, Alertable, &timeout, waitblocks);在这里，objects指向一个指针数组，每个数组元素指向一个同步对象，count是数组中指针的个数。count必须小于或等于MAXIMUM_WAIT_OBJECTS值(当前为64)。这个数组和它所指向的所有对象都必须在非分页内存中。WaitType是枚举类型，其值可以为WaitAll或WaitAny，它指出你是等到所有对象都进入信号态，还是只要有一个对象进入信号态就可以。
waitblocks参数指向一个KWAIT_BLOCK结构数组，内核用这个结构数组管理等待操作。你不需要初始化这些结构，内核仅需要知道这个结构数组在哪里，内核用它来记录每个对象在等待中的状态。如果你仅需要等待小数量的对象(不超过THREAD_WAIT_OBJECTS，该值当前为3)，你可以把该参数指定为NULL。如果该参数为NULL，KeWaitForMultipleObjects将使用线程对象中预分配的等待块数组。如果你等待的对象数超过THREAD_WAIT_OBJECTS，你必须提供一块长度至少为count * sizeof(KWAIT_BLOCK)的非分页内存。
其余参数与KeWaitForSingleObject中的对应参数作用相同，而且大部分返回码也有相同的含义。
如果你指定了WaitAll，则返回值STATUS_SUCCESS表示等待的所有对象都进入了信号态。如果你指定了WaitAny，则返回值在数值上等于进入信号态的对象在objects数组中的索引。如果碰巧有多个对象进入了信号态，则该值仅代表其中的一个，可能是第一个也可能是其它。你可以认为该值等于STATUS_WAIT_0加上数组索引。你可以先用NT_SUCCESS测试返回码，然后再从其中提取数组索引：
NTSTATUS status = KeWaitForMultipleObjects(...);if (NT_SUCCESS(status)){ ULONG iSignalled = (ULONG) status - (ULONG) STATUS_WAIT_0; ...}如果KeWaitForMultipleObjects返回成功代码，它也将执行等待被满足的那个对象的附加动作。如果多个对象同时进入信号态而你指定的WaitType参数为WaitAny，那么该函数仅执行返回值指定对象的附加动作。
内核事件
表4-2列出了用于处理内核事件的服务函数。为了初始化一个事件对象，我们首先应该为其分配非分页存储，然后调用KeInitializeEvent：
ASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);KeInitializeEvent(event, EventType, initialstate);event是事件对象的地址。EventType是一个枚举值，可以为NotificationEvent或SynchronizationEvent。通知事件(notification event)有这样的特性，当它进入信号态后，它将一直处于信号态直到你明确地把它重置为非信号态。此外，当通知事件进入信号态后，所有在该事件上等待的线程都被释放。这与用户模式中的手动重置事件相似。而对于同步事件(synchronization event)，只要有一个线程被释放，该事件就被重置为非信号态。这又与用户模式中的自动重置事件相同。而KeWaitXxx函数在同步事件对象上执行的附加动作就是把它重置为非信号态。最后的参数initialstate是布尔量，为TRUE表示事件的初始状态为信号态，为FALSE表示事件的初始状态为非信号态。
表4-2. 用于内核事件对象的服务函数
在这些关于同步原语的段中，我还要再谈论一下DDK文档中对IRQL的使用限定。在当前发行的Windows 2000中，DDK有时比OS实际要求的有更多的限制。例如，KeClearEvent可以在任何IRQL上调用，但DDK却要求调用者必须在低于或等于DISPATCH_LEVEL级上调用。KeInitializeEvent也可以在任何IRQL上调用，但DDK要求仅在PASSIVE_LEVEL级上调用该函数。然而，你应该尊重DDK中的描述，也许某一天Microsoft会利用文档中的这些限制。
调用KeSetEvent函数可以把事件置为信号态：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LONG wassignalled = KeSetEvent(event, boost, wait);在上面代码中，ASSERT语句强制你必须在低于或等于DISPATCH_LEVEL级上调用该函数。event参数指向一个事件对象，boost值用于提升等待线程的优先级。wait参数的解释见文字框“KeSetEvent的第三个参数”，WDM驱动程序几乎从不把wait参数指定为TRUE。如果该事件已经处于信号态，则该函数返回非0值。如果该事件处于非信号态，则该函数返回0。
多任务调度器需要人为地提升等待I/O操作或同步对象的线程的优先级，以避免饿死长时间等待的线程。这是因为被阻塞的线程往往是放弃自己的时间片并且不再要求获得CPU，但只要这些线程获得了比其它线程更高的优先级，或者其它同一优先级的线程用完了自己的时间片，它们就可以恢复执行。注意，正处于自己时间片中的线程不能被阻塞。
用于提升阻塞线程优先级的boost值不太好选择。一个较好的笨方法是指定IO_NO_INCREMENT值，当然，如果你有更好的值，可以不用这个值。如果事件唤醒的是一个处理时间敏感数据流的线程(如声卡驱动程序)，那么应该使用适合那种设备的boost值(如IO_SOUND_INCREMENT)。重要的是，不要为一个愚蠢的理由去提高等待者的优先级。例如，如果你要同步处理一个IRP_MJ_PNP请求，那么在你要停下来等待低级驱动程序处理完该IRP时，你的完成例程应调用KeSetEvent。由于PnP请求对于处理器没有特殊要求并且也不经常发生，所以即使是声卡驱动程序也也应该把boost参数指定为IO_NO_INCREMENT。
调用KeReadStateEvent函数(在任何IRQL上)可以测试事件的当前状态：
LONG signalled = KeReadStateEvent(event);返回值不为0代表事件处于信号态，为0代表事件处于非信号态。
Windows 98不支持KeReadStateEvent函数，但支持上面描述的其它KeReadStateXxx函数。为了获得事件的状态，我们必须使用Windows 98的其它同步原语。
调用KeResetEvent函数(在低于或等于DISPATCH_LEVEL级)可以立即获得事件对象的当前状态，但该函数会把事件对象重置为非信号状态。
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LONG signalled = KeResetEvent(event);如果你对事件的上一个状态不感兴趣，可以调用KeClearEvent函数，象下面这样：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);KeClearEvent(event);KeClearEvent函数执行得更快，因为它在读取事件的当前状态后不设置事件为非信号态。
内核信号灯
内核模式信号灯是一个有同步语义的整数计数器。信号灯计数器为正值时代表信号态，为0时代表非信号态。计数器不能为负值。释放信号灯将使信号灯计数器增1，在一个信号灯上等待将使该信号灯计数器减1。如果计数器值被减为0，则信号灯进入非信号态，之后其它调用KeWaitXxx函数的线程将被阻塞。注意如果等待线程的个数超过了计数器的值，那么并不是所有等待的线程都可以恢复运行。
内核提供了三个服务函数来控制信号灯对象的状态。(见表4-3) 信号灯对象应该在PASSIVE_LEVEL级上初始化：
ASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);KeInitializeSemaphore(semaphore, count, limit);在这个调用中，semaphore参数指向一个在非分页内存中的KSEMAPHORE对象。count是信号灯计数器的初始值，limit是计数器能达到的最大值，它必须与信号灯计数器的初始值相同。
表4-3. 内核信号灯对象服务函数
如果你创建信号灯时指定limit参数为1，则该对象与仅有一个线程的互斥对象类似。但内核互斥对象有一些信号灯没有的特征，这些特征用于防止死锁。所以，没有必要创建limit为1的信号灯。
如果你以一个大于1的limit值创建信号灯， 则该信号灯允许多个线程同时访问某些资源。在队列理论中我们会发现同样的原理，单队列可以被多个服务程序使用。多个服务程序使用一个队列要比每个服务程序都有各自的队列更合理。这两种形式的平均等待时间是相同的，但前者的等待次数更少。使用信号灯，你可以把一组软件或硬件服务程序按照队列原理组织起来。
信号灯的所有者可以调用KeReleaseSemaphore函数释放信号灯：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LONG wassignalled = KeReleaseSemaphore(semaphore, boost, delta, wait);这里出现了一个delta参数，它必须为正数，该函数把delta值加到semaphore指向的信号灯计数器上，这将把信号灯带入信号态，并使等待线程释放。通常，该参数应该指定为1，代表有一个所有者释放了它的权利。boost和wait参数与在KeSetEvent函数中的作用相同。返回值为0代表信号灯的前一个状态是非信号态，非0代表信号灯的前一个状态为信号态。
KeReleaseSemaphore不允许你把计数器的值增加到超过limit指定的值。如果你这样做，该函数根本就不调整计数器的值，它将产生一个代码为STATUS_SEMAPHORE_LIMIT_EXCEEDED的异常。除非系统中存在捕获该异常的处理程序，否则将导致一个bug check。
下面调用读取信号灯的当前状态：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LONG signalled = KeReadStateSemaphore(semaphore);非0返回值表示信号灯处于信号态，0返回值代表信号灯为非信号态。不要把该返回值假定为计数器的当前值。
内核同步对象（下）
内核互斥对象
互斥(mutex)就是互相排斥(mutual exclusion)的简写。内核互斥对象为多个竞争线程串行化访问共享资源提供了一种方法(不一定是最好的方法)。如果互斥对象不被某线程所拥有，则它是信号态，反之则是非信号态。当线程为了获得互斥对象的控制权而调用KeWaitXxx例程时，内核同时也做了一些工作以帮助避免可能的死锁。同样，互斥对象也需要与KeWaitForSingleObject类似的附加动作。内核可以确保线程不被换出，并且阻止所有APC的提交，内核专用APC(如IoCompleteRequest用以完成I/O请求的APC)除外。
通常我们应该使用executive部件输出的快速互斥对象而不是内核互斥对象。这两者的主要不同是，内核互斥可以被递归获取，而executive快速互斥则不能。即内核互斥的所有者可以调用KeWaitXxx并指定所拥有的互斥对象从而使等待立即被满足。如果一个线程真的这样做，它必须也要以同样的次数释放该互斥对象，否则该互斥对象不被认为是空闲的。
如果你需要长时间串行化访问一个对象，你应该首先考虑使用互斥(而不是依赖提升的IRQL和自旋锁)。利用互斥对象控制资源的访问，可以使其它线程分布到多处理器平台上的其它CPU中运行，还允许导致页故障的代码仍能锁定资源而不被其它线程访问。表4-4列出了互斥对象的服务函数。
表4-4. 互斥对象服务函数
为了创建一个互斥对象，你需要为KMUTEX对象保留一块非分页内存，然后象下面这样初始化：
ASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);KeInitializeMutex(mutex, level);mutex是KMUTEX对象的地址，level参数最初是用于辅助避免多互斥对象带来的死锁。但现在，内核忽略level参数。
互斥对象的初始状态为信号态，即未被任何线程拥有。KeWaitXxx调用将使调用者接管互斥对象的控制并使其进入非信号态。
利用下面函数可以获取互斥对象的当前状态：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LONG signalled = KeReadStateMutex(mutex);返回值0表示互斥对象已被占用，非0表示未被占用。
下面函数可以使所有者放弃其占有的互斥对象并使其进入信号态：
ASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);LONG wassignalled = KeReleaseMutex(mutex, wait);wait参数与KeSetEvent函数中的含义相同。该函数返回值总是0，表示该互斥对象曾被占用过，如果不是这种情况(所有者释放的不是它自己的对象)，KeReleaseMutex将产生bug check。
出于完整性的考虑，我想提一下KeWaitForMutexObject函数，它是DDK中的宏(见WDM.H)。其定义如下：
#define KeWaitForMutexObject KeWaitForSingleObject内核定时器
内核还提供了一种定时器对象，该对象可以在指定的绝对时间或间隔时间后自动从非信号态变为信号态。它还可以周期性地进入信号态。我们可以用它来安排一个定期执行的DPC回调函数。表4-5列出了用于定时器对象的服务函数。
表4-5. 内核定时器对象的服务函数
在这一段中，我们将创建一个通知定时器对象并等到它达到预定时间。首先，我们在非分页内存中分配一个KTIMER对象。然后，我们在低于或等于DISPATCH_LEVEL级上初始化这个定时器对象：
PKTIMER timer; // someone gives you thisASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);KeInitializeTimer(timer);在此，定时器处于非信号状态，它还没有开始倒计时，在这样的定时器上等待的线程永远得不到唤醒。为了启动定时器倒计时，我们调用KeSetTimer函数：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LARGE_INTEGER duetime;BOOLEAN wascounting = KeSetTimer(timer, duetime, NULL);duetime是一个64位的时间值，单位为100纳秒。如果该值为正，则表示一个从1601年1月1日算起的绝对时间。如果该值为负，则它是相对于当前时间的一段时间间隔。
返回值如果为TRUE，则表明定时器已经启动。(在这种情况下，如果我们再调用KeSetTimer函数，则定时器放弃原来的时间重新开始倒计时)
下面语句读取定时器的当前状态：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);BOOLEAN counting = KeReadStateTimer(timer);KeInitializeTimer和KeSetTimer实际上是旧的服务函数，它们已经被新函数取代。我们可以用下面调用初始化定时器：
ASSERT(KeGetCurrentIqrl() <= DISPATCH_LEVEL);KeInitializeTimerEx(timer, NotificationTimer);定时器设置函数也有扩展版本，KeSetTimerEx：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LARGE_INTEGER duetime;BOOLEAN wascounting = KeSetTimerEx(timer, duetime, 0, NULL);我将在本章后面解释该函数扩展版本的新参数。
即使定时器开始倒计时，它仍处于非信号态，直到到达指定的时间。在那个时刻，该定时器对象自动变为信号态，所有等待的线程都被释放。
在这一小节中，我们想让定时器去触发一个DPC例程。使用这种方法，不论你的线程有什么优先级都会响应超时事件。(因为线程只能在PASSIVE_LEVEL级上等待，而定时器到时间后，获取CPU控制权的线程是随机的。然而，DPC例程执行在提升的IRQL级上，它可以有效地抢先所有线程)
我们用同样的方法初始化定时器对象。另外我们还再初始化一个KDPC对象，该对象应该在非分页内存中分配。如下面代码：
PKDPC dpc; // points to KDPC you've allocatedASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);KeInitializeTimer(timer);KeInitializeDpc(dpc, DpcRoutine, context);用KeInitializeTimer或KeInitializeTimerEx初始化定时器对象。DpcRoutine是一个DPC(推迟过程调用)例程的地址，这个例程必须存在于非分页内存中。context参数是一个任意的32位值(类型为PVOID)，它将作为参数传递给DPC例程。dpc参数是一个指向KDPC对象的指针(该对象必须在非分页内存中。例如，在你的设备扩展中)。
当开始启动定时器的倒计时，我们把DPC对象指定为KeSetTimer或KeSetTimerEx函数的一个参数：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LARGE_INTEGER duetime;BOOLEAN wascounting = KeSetTimer(timer, duetime, dpc);这个KeSetTimer调用与上一段中的调用的不同之处是，我们在最后一个参数中指定了一个DPC对象地址。当定时器时间到时，系统将把该DPC排入队列，并且只要条件允许就立即执行它。在最差的情况下，它也与在PASSIVE_LEVEL级上唤醒线程一样快。DPC函数的定义如下：
VOID DpcRoutine(PKDPC dpc, PVOID context, PVOID junk1, PVOID junk2){ ...}即使你为KeSetTimer或KeSetTimerEx提供了DPC参数，你仍可以调用KeWaitXxx函数使自己在PASSIVE_LEVEL级上等待。在单CPU的系统上，DPC将在等待完成前执行，因为它执行在更高的IRQL上。
同步定时器
与事件对象类似，定时器对象也有两种形式：通知方式和同步方式。通知定时器允许有任意数量的等待线程。同步定时器正相反，它只允许有一个等待线程。一旦有线程在这种定时器上等待，定时器就自动进入非信号态。为了创建同步定时器，你必须使用扩展形式的初始化函数：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);KeInitializeTimerEx(timer, SynchronizationTimer);SynchronizationTimer是枚举类型TIMER_TYPE的一个枚举值。另一个枚举值是NotificationTimer。
如果你在同步定时器上使用DPC例程，可以把排队DPC看成是定时器到期时发生的额外事情。即定时器到期时，系统把定时器置成信号态，并把DPC对象插入DPC队列。定时器进入信号态将使阻塞的线程得以释放。
周期性定时器
到现在为止，我们讨论过的定时器仅能定时一次。通过使用定时器的扩展设置函数，你可以请求一个周期性的超时：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);LARGE_INTEGER duetime;BOOLEAN wascounting = KeSetTimerEx(timer, duetime, period, dpc);这里，period是周期超时值，单位为毫秒(ms)，dpc是一个可选的指向KDPC对象的指针。这种定时器在第一次倒计时时使用duetime时间，到期后再使用period值重复倒计时。为了准确地完成周期定时，应该把duetime时间指定为与周期间隔参数一样的相对时间。指定为0的duetime参数将使定时器立即完成第一次倒计时，然后开始周期性倒计时。由于不用重复等待超时通知，所以周期性定时器常常与DPC对象联用。
取消一个周期性定时器
在定时器对象超出定义范围之外前，一定要调用KeCancelTimer取消任何已创建的周期性定时器。如果这个周期性定时器带有一个DPC，则还需要在取消该定时器之后调用KeRemoveQueueDpc。甚至即使你做了这两件事，还可能出现一个无法解决的问题。如果你在DriverUnload例程中取消这种定时器，可能会出现一种罕见的情形：你的驱动程序已被卸载，但那个DPC例程的实例却仍运行在另一个CPU上。这个问题只有等待未来版本的操作系统来解决。你可以尽早地取消这种定时器以便减少该问题出现的可能性，比如在IRP_MN_REMOVE_DEVICE的处理程序中。
一个例子
内核定时器的一个用处是为定期检测设备活动的系统线程提供循环定时。今天很少有设备需要循检服务，但你可能遇到例外情况。我将在第九章中讨论这个主题。随书光盘中有一个例子(POLLING)演示了这个概念。这个例子的部分代码以固定的间隔时间循检设备。这个循环可以被设置的kill事件所打破，所以程序使用了KeWaitForMultipleObjects函数。实际的代码要比下面的例子更复杂一些，下面代码片段主要侧重于定时器的使用：
VOID PollingThreadRoutine(PDEVICE_EXTENSION pdx){ NTSTATUS status; KTIMER timer; KeInitializeTimerEx(&timer, SynchronizationTimer); <--1 PVOID pollevents[] = { <--2 (PVOID) &pdx->evKill, (PVOID) &timer, }; ASSERT(arraysize(pollevents) <= THREAD_WAIT_OBJECTS); LARGE_INTEGER duetime = {0}; #define POLLING_INTERVAL 500 KeSetTimerEx(&timer, duetime, POLLING_INTERVAL, NULL); <--3 while (TRUE) { status = KeWaitForMultipleObjects(arraysize(pollevents), <--4 pollevents, WaitAny, Executive, KernelMode, FALSE, NULL, NULL); if (status == STATUS_WAIT_0) break; if (<device needs attention>) <--5 <do something>; } KeCancelTimer(&timer); PsTerminateSystemThread(STATUS_SUCCESS);}- 在此，我们把一个内核定时器初始化成同步方式。它只能用于一个线程，本线程。
- 我们需要为KeWaitForMultipleObjects函数提供一个同步对象指针数组。第一个数组元素是kill事件对象，驱动程序的其它部分可能在系统线程需要退出时设置这个对象，以终止循环。第二个数组元素就是定时器对象。
- KeSetTimerEx语句启动周期定时器。由于duetime参数是0，所以定时器立即进入信号态。然后每隔500毫秒触发一次。
- 在循检循环内，我们等待定时器到期或kill事件发生。如果等待由于kill事件而结束，我们退出循环，并做一些清理工作，最后终止这个系统线程。如果等待是由定时器到期而结束，我们就前进到下一步处理。
- 在这里，设备驱动程序可以做一些与硬件有关的操作。
定时函数
除了使用内核定时器对象外，你还可以使用另外两个定时函数，它们也许更适合你。第一函数是KeDelayExecutionThread，你可以在PASSIVE_LEVEL级上调用该函数并给出一个时间间隔。该函数省去了使用定时器时的麻烦操作，如创建，初始化，设置，等待操作。
ASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);LARGE_INTEGER duetime;NSTATUS status = KeDelayExecutionThread(WaitMode, Alertable, &duetime);在这里，WaitMode、Alertable，和函数返回代码与KeWaitXxx中的对应部分有相同的含义。duetime也是内核定时器中使用的同一种时间表达类型。
如果你需要延迟一段非常短的时间(少于50毫秒)，可以调用KeStallExecutionProcessor，在任何IRQL级上：
KeStallExecutionProcessor(nMicroSeconds);这个延迟的目的是允许硬件在程序继续执行前有时间为下一次操作做准备。实际的延迟时间可能大大超过你请求的时间，因为KeStallExecutionProcessor可以被其它运行在更高IRQL级上的活动抢先，但不能被同一IRQL级上的活动抢先。
内核线程同步
操作系统的进程结构部件(Process Structure)提供了一些例程，WDM驱动程序可以使用这些例程创建和控制内核线程，这些例程可以帮助驱动程序周期性循检设备，我将在第九章中讨论这些例程。出于完整性考虑，我在这里先提一下。如果在KeWaitXxx调用中指定一个内核线程对象，那么你的线程将被阻塞直到那个内核线程结束运行。那个内核线程通过调用PsTerminateSystemThread函数终止自身。
为了等待某内核线程结束，你首先应获得一个KTHREAD对象(不透明对象)的指针，在内部，该对象用于代表内核线程，但这里还有一点问题，当你运行在某线程的上下文中时，你可以容易地获取当前线程的KTHREAD指针：
ASSERT(KeGetCurrentIrql() <= DISPATCH_LEVEL);PKTHREAD thread = KeGetCurrentThread();不幸的是，当你调用PsCreateSystemThread创建新内核线程时，你仅能获取该线程的不透明句柄。为了获得KTHREAD对象指针，你必须使用对象管理器服务函数：
HANDLE hthread;PKTHREAD thread;PsCreateSystemThread(&hthread, ...);ObReferenceObjectByHandle(hthread, THREAD_ALL_ACCESS, NULL, KernelMode, (PVOID*) &thread, NULL);ZwClose(hthread);ObReferenceObjectByHandle函数把你提供的句柄转换成一个指向下层内核对象的指针。一旦有了这个指针，你就可以调用ZwClose关闭那个句柄。在某些地方，你还需要调用ObDereferenceObject函数释放对该线程对象的引用。
ObDereferenceObject(thread);线程警惕和APC在内部，Windows NT内核有时使用线程警惕(thread alert)来唤醒线程。这种方法使用APC(异步过程调用)来唤醒线程去执行某些特殊例程。用于生成警惕和APC的支持例程没有输出给WDM驱动程序开发者使用。但是，由于DDK文档和头文件中有大量地方引用了这个概念，所以我想在这里谈一下。
当某人通过调用KeWaitXxx例程阻塞一个线程时，需要指定一个布尔参数，该参数表明等待是否是警惕的(alertable)。一个警惕的等待可以提前完成，即不用满足任何等待条件或超时，仅由于线程警惕。线程警惕起源于用户模式的native API函数NtAlertThread。如果因为警惕等待提前终止，则内核返回特殊的状态值STATUS_ALERTED。
APC机制使操作系统能在特定线程上下文中执行一个函数。APC的异步含义是，系统可以有效地中断目标线程以执行一个外部例程。APC的动作有点类似于硬件中断使处理器从任何当前代码突然跳到ISR的情形，它是不可预见的。
APC来自三种地方：用户模式、内核模式，和特殊内核模式。用户模式代码通过调用Win32 API函数QueueUserAPC请求一个用户模式APC。内核模式代码通过调用一个未公开的函数请求一个APC，而且该函数在DDK头文件中没有原型。某些逆向工程师可能已经知道该例程的名称以及如何调用它，但该函数的确是仅用于内部，所以我不在这里讨论它。系统把APC排入一个特殊线程直到和适的执行条件出现。和适的执行条件要取决于APC的类型，如下：
- 特殊的内核APC被尽可能快地执行，既只要APC_LEVEL级上有可调度的活动。在很多情况下，特殊的内核APC甚至能唤醒阻塞的线程。
- 普通的内核APC仅在所有特殊APC都被执行完，并且目标线程仍在运行，同时该线程中也没有其它内核模式APC正执行时才执行。
- 用户模式APC在所有内核模式APC执行完后才执行，并且仅在目标线程有警惕属性时才执行。
如果系统唤醒线程去提交一个APC，则使该线程阻塞的等待原语函数将返回特殊状态值STATUS_KERNEL_APC或STATUS_USER_APC。
APC与I/O请求
内核使用APC概念有多种目的。由于本书仅讨论驱动程序的编写，所以我仅解释APC与执行I/O操作之间的关系。在某些场合，当用户模式程序在一个句柄上执行同步的ReadFile操作时，Win32子系统就调用一个名为NtReadFile(尽管未公开，但已经被广泛了解)的内核模式例程。该函数创建并提交一个IRP到适当的设备驱动程序，而驱动程序通常返回STATUS_PENDING以指出操作未完成。NtReadFile然后向ReadFile也返回这个状态代码，于是ReadFile调用NtWaitForSingleObject函数，这将使应用程序在那个用户模式句柄指向的文件对象上等待。NtWaitForSingleObject接着调用KeWaitForSingleObject以执行一个非警惕的用户模式的等待，在文件对象内部的一个事件对象上等待。
当设备驱动程序最后完成了读操作时，它调用IoCompleteRequest函数，该函数接下来排队一个特殊的内核模式APC。该APC例程然后调用KeSetEvent函数使文件对象进入信号态，因此应用程序被释放并得以继续执行。有时，I/O请求被完成后还需要执行一些其它任务，如缓冲区复制，而这些操作又必须发生在请求线程的地址上下文中，因此会需要其它种类的APC。如果请求线程不处于警惕性的等待状态，则需要内核模式APC。如果在提交APC时线程并不适合运行，则需要特殊的APC。实际上，APC例程就是用于唤醒线程的机制。
内核模式例程也能调用NtReadFile函数。但驱动程序应该调用ZwReadFile函数替代，它使用与用户模式程序一样的系统服务接口到达NtReadFile(注意，NtReadFile函数未公开给设备驱动程序使用)。如果你遵守DDK的限定调用ZwReadFile函数，那么你向NtReadFile的调用与用户模式中的调用几乎没有什么不同，仅有两处不同。第一，ZwReadFile函数更小，并且任何等待都将在内核中完成。另一个不同之处是，如果你调用了ZwCreateFile函数并指定了同步操作，则I/O管理器将自动等待你的读操作直到完成。这个等待可以是警惕的也可以不是，取决于你在ZwCreateFile调用中指定的实际选项。
如何指定Alertable和WaitMode参数
现在你已经有足够的背景资料了解等待原语中的Alertable和WaitMode参数。作为一个通用规则，你绝不要写同步响应用户模式请求的代码，仅能为确定的I/O控制请求这样做。一般说来，最好挂起长耗时的操作(从派遣例程中返回STATUS_PENDING代码)而以异步方式完成。再有，你不要一上来就调用等待原语。线程阻塞仅适合设备驱动程序中的某几个地方使用。下面几段介绍了这几个地方。
内核线程 有时，当你的设备需要周期性循检时，你需要创建自己的内核模式线程。
处理PnP请求 我将在第六章中讨论如何处理PnP管理器发送给你的I/O请求。有几个PnP请求需要你在驱动程序这边同步处理。换句话说，你把这些请求传递到低级驱动程序并等待它们完成。你将调用KeWaitForSingleObject函数并在内核模式中等待，这是由于PnP管理器是在内核模式线程的上下文中调用你的驱动程序。另外，如果你需要执行作为处理PnP请求一部分的辅助请求时，例如，与USB设备通信，你应在内核模式中等待。
处理其它I/O请求 当你正在处理其它种类的I/O请求时，并且你知道正运行在一个非任意线程上下文中时，那么你在行动前必须仔细考虑，如果你确信那个线程可以被阻塞，你应该在调用者所处于的处理器模式中等待。在多数情况下，你可以利用IRP中的RequestorMode域。此外，你还可以调用ExGetPreviousMode来确定前一个处理器模式。如果你在用户模式中等待，并允许用户程序调用QueueUserAPC提前终止等待，你应该执行一个警惕性等待。
我最后要提到的情况是，在用户模式中等待并要允许用户模式APC打断，你应使用警惕性等待。
底线是：使用非警惕性等待，除非你知道不这样做的原因。
- 内核同步对象
- 【转帖】内核同步对象
- 内核同步对象(下)
- 内核同步对象
- -【内核对象线程同步】信标内核对象
- -【内核对象线程同步】事件内核对象
- 用内核对象同步线程
- 利用内核对象同步线程
- 内核同步对象（上）
- 内核同步对象（下）
- 内核同步对象（上）
- -【内核对象线程同步】概述
- 几个处理同步内核对象
- 线程同步--事件内核对象
- 线程同步--信号量内核对象
- 内核对象的线程同步
- 内核对象用于线程同步
- 线程同步 总结 内核对象
- HashTable
- 谨慎驱动开发
- Linux_分页管理机制（线性地址转换到物理地址）
- 《程序员的第一年》---------- 程序员的第一年怎么过
- 网页重要性与PageRank的理解
- 内核同步对象
- 使用JCS时出现config.OptionConverter - Could not instantiate class []的错误原因
- 程序人生--2000年(1)
- linux 文件编码格式转换
- audio：mt6236 录音驱动小结
- Windbg调试
- 深入讨论C++的enum
- Android Unable to resolve target 'android-8'
- TCP/IP详解--第十八章
