内核同步对象（上）

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返回值代表信号灯为非信号态。不要把该返回值假定为计数器的当前值。