内核同步对象

转 https://blog.csdn.net/lqk1985/article/details/2541867

Windows NT提供了五种内核同步对象(Kernel Dispatcher Object)，你可以用它们控制非任意线程(普通线程)的流程。表4-1列出了这些内核同步对象的类型及它们的用途。在任何时刻，任何对象都处于两种状态中的一种：信号态或非信号态。有时，当代码运行在某个线程的上下文中时，它可以阻塞这个线程的执行，调用KeWaitForSingleObject或KeWaitForMultipleObjects函数可以使代码(以及背景线程)在一个或多个同步对象上等待，等待它们进入信号态。内核为初始化和控制这些对象的状态提供了例程。

表4-1. 内核同步对象

对象	数据类型	描述
Event(事件)	KEVENT	阻塞一个线程直到其它线程检测到某事件发生
Semaphore(信号灯)	KSEMAPHORE	与事件对象相似，但可以满足任意数量的等待
Mutex(互斥)	KMUTEX	执行到关键代码段时，禁止其它线程执行该代码段
Timer(定时器)	KTIMER	推迟线程执行一段时期
Thread(线程)	KTHREAD	阻塞一个线程直到另一个线程结束

在下几段中，我将描述如何使用内核同步对象。我将从何时可以调用等待原语阻塞线程开始讲起，然后讨论用于每种对象的支持例程。最后讨论与线程警惕(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函数可以获得当前系统时间。负数代表相对于当前时间的时间间隔。如果你指定了绝对超时，那么系统时钟的改变也将影响到你的超时时间。如果系统时间越过你指定的绝对时间，那么永远都不会超时。相反，如果你指定相对超时，那么你经过的超时时间将不受系统时钟改变的影响。

为什么是1601年1月1日

许多年以前，当我第一次学习Win32 API时，我曾迷惑为什么选择1601年1月1日作为Windows NT的时间起点。在我写了一组时间转换函数后我明白了这个问题的原因。每个人都知道可被4整除的年份是闰年。许多人也知道世纪年(如1900年)应例外，虽然这些年份都能被4整除但它们不是闰年。少数人还知道能被400整除的年份(如1600和2000)是例外中的例外，它们也是闰年。而1601年1月1日正好是一个400年周期的开始。如果把它作为时间信息的起点，那么把NT时间信息转换为常规日期表达(或相反)就不用做任何跳跃操作。

指定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. 用于内核事件对象的服务函数

服务函数	描述
KeClearEvent	把事件设置为非信号态，不报告以前的状态
KeInitializeEvent	初始化事件对象
KeReadStateEvent	取事件的当前状态
KeResetEvent	把事件设置为非信号态，返回以前的状态
KeSetEvent	把事件设置为信号态，返回以前的状态

注意

在这些关于同步原语的段中，我还要再谈论一下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。

KeSetEvent的第三个参数

wait参数的目的是允许在内部快速地把控制从一个线程传递到另一个线程。除了设备驱动程序之外，大部分系统部件都可以创建双事件对象。例如，客户线程和服务器线程使用双事件对象来界定它们的通信。当服务器线程需要唤醒对应的客户线程时，它首先调用KeSetEvent函数，并指定wait参数为TRUE，然后立即调用KeWaitXxx函数使自己进入睡眠状态。由于这两个操作都以原子方式完成，所以在控制交接时没有其它线程被唤醒。

DDK总是稍稍地描述一些内部细节，但我发现有些描述另人迷惑。我将以另一种方式解释这些内部细节，看过这些细节后你就会明白为什么我们总指定这个参数为FALSE。在内部，内核使用一个“同步数据库锁(dispatcher database lock)”来保护线程的阻塞、唤醒，和调度操作。KeSetEvent函数需要获取这个锁，KeWaitXxx函数也是这样。如果你把这个参数指定为TRUE，则KeSetEvent函数将设置一个标志以便KeWaitXxx函数知道你使用了TRUE参数，然后它返回，并且不释放这个锁。当你后来(应该立即调用，因为你此时正运行在一个比任何硬件设备都高的IRQL上，并且你占有着一个被极其频繁争夺的自旋锁)调用KeWaitXxx函数时，它不必再获取这个锁。产生的效果就是你唤醒了等待的线程并同时把自己置入睡眠状态，而不给其它线程任何运行的机会。

你应该明白，以wait参数为TRUE调用KeSetEvent的函数必须存在于非分页内存中，因为它在某段时间内执行在提升的IRQL上。很难想象一个普通设备驱动程序会需要使用这种机制，因为驱动程序决不会比内核更了解线程的调度。底线是：对该参数总使用FALSE。实际上，Microsoft暴露该参数给我们的原因仍不十分清楚。

调用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. 内核信号灯对象服务函数

服务函数	描述
KeInitializeSemaphore	初始化信号灯对象
KeReadStateSemaphore	取信号灯当前状态
KeReleaseSemaphore	设置信号灯对象为信号态

如果你创建信号灯时指定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. 互斥对象服务函数

服务函数	描述
KeInitializeMutex	初始化互斥对象
KeReadStateMutex	取互斥对象的当前状态
KeReleaseMutex	设置互斥对象为信号态

为了创建一个互斥对象，你需要为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. 内核定时器对象的服务函数

服务函数	描述
KeCancelTimer	取消一个活动的定时器
KeInitializeTimer	初始化一次性的通知定时器
KeInitializeTimerEx	初始化一次性的或重复通知的或同步的定时器
KeReadStateTimer	获取定时器的当前状态
KeSetTimer	为通知定时器设定时间
KeSetTimerEx	为定时器设定时间和其它属性

通知定时器用起来象事件

在这一段中，我们将创建一个通知定时器对象并等到它达到预定时间。首先，我们在非分页内存中分配一个KTIMER对象。然后，我们在低于或等于DISPATCH_LEVEL级上初始化这个定时器对象：

PKTIMER timer;      //  someone gives you this
ASSERT(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 allocated
ASSERT(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的类型，如下：