Win2000服务器端应用程序开发设计指南-设备I/O及线程间通讯

接收完成的I/O请求通知
　

此时，您已知道如何要求一个非同步设备I/O请求，但还没讨论到设备驱动程序在I/O请求完成后会如何通知您。

为了接收I/O完成通知，Windows提供了四个不同的方法（表2-9中有简短的叙述），本章涵盖了所有的方法。这些方法依复杂性的高低列出，从最容易理解及实作（通知设备核心物件）到最难理解及实作（I/O完成端口）。

就像本章一开始所陈述的，I/O完成端口是四个接收I/O完成通知方法中最容易且有效的。经由学会这四个方法，您将会得知Microsoft将I/O完成端口加到Windows的原因以及I/O通讯埠解决因其他方法而存在的所有问题之方法。

通知设备核心物件
　

一旦线程发布了非同步的I/O请求，它仍旧会执行其他有用的工作，到了最后，线程会需要与I/O操作同时完成。换言之，除非将从设备传入来的资料完全载入缓冲器中，否则您将在线程的程序代码中碰撞到某个线程无法继续执行的位置。

在Windows中，设备核心物件能被当成线程同步化物件来使用，所以该物件可以是通知或非通知状态。在伫列I/O请求之前，ReadFile及WriteFile函数会将设备核心物件设定为非通知状态。当设备驱动程序完成请求时，驱动程序则将设备核心物件设定为通知状态。一个线程可以决定某个I/O请求是否经由呼叫WaitForSingleObject或WaitForMultipleObjects完成。以下有个简单的例子：

HANDLE hfile = CreateFile(..., FILE_FLAG_OVERLAPPED, ...); 
BYTE bBuffer[100];
OVERLAPPED o = { 0 };
o.Offset = 345;
BOOL fReadDone = ReadFile(hfile, bBuffer, 100, NULL, &o);
DWORD dwError = GetLastError();
if (!fReadDone && (dwError == ERROR_IO_PENDING)) {
 // I/O被非同步地执行；等待它完成
 WaitForSingleObject(hfile, INFINITE);
 fReadDone = TRUE;
}
if (fReadDone) {
 // o.Internal包含I/O错误
 // o.InternalHigh包含转移位元组的数量
 // bBuffer包含读取的资料
} else {
 // 发生某个错误：请查看dwError
}

这个程序代码发布了一个非同步I/O请求，然后立即等待请求的结束，最后使得非同步I/O的目的失败！显然地，您大概从未实际地编写过类似的程序代码，但这个程序代码的确说明了即将在这里叙述的重要观念：

通知事件核心物件
　

刚才叙述之接收I/O完成通知方法是非常简单且明确的，但其结果并非完全有帮助，因为它没有把多重I/O请求处理的很好。举例来说，假设您试图于同一时间在单一的文件上实作多重之非同步操作。假定您想要同时从文件中读取10个位元组并且写入10个位元组至文件中。它的程序代码可能看起来像这个样子：

HANDLE hfile = CreateFile(..., FILE_FLAG_OVERLAPPED, ...); 
BYTE bBuffer[10];
OVERLAPPED oRead = { 0 };
oRead.Offset = 0;
ReadFile(hfile, bBuffer, 10, NULL, &oRead);
OVERLAPPED oWrite = { 0 };
oWrite.Offset = 10;
WriteFile(hfile, "Jeff", 5, NULL, &oWrite);
.
.
.
WaitForSingleObject(hfile, INFINITE);
// 我们不知道完成了什么：读取？写入？或两者都是？

您不能经由等待设备变成通知状态而使线程同时产生，因为操作一完成，物件就会变成通知的状态。假如您呼叫WaitForSingleObject并且传递设备handle给它，因为在读取、写入操作的完成或者两者皆已完成的情形下，您将没有把握函数是否会被返回。显然地，那里需要一个更好的方式去执行多重、同步之非同步I/O请求，以使您不会遇到这个困境-幸运的是，那里的确有。

OVERLAPPED结构的最后一个成员—hEvent，它识别某个事件之核心物件。您必须经由呼叫CreateEvent来建立这个事件物件。当一个非同步I/O请求完成时，设备驱动程序会检查OVERLAPPED结构的hEvent成员是否为NULL。假如hEvent不是NULL，则设备会经由呼叫SetEvent来通知这个事件。驱动程序也将设备物件设定为通知状态就如同之前所做的。然而，假如您使用事件去决定一个设备操作什么时候完成，则您不应等待设备物件变成通知状态-即以等待事件来取代。

假如您想要同时执行多重之非同步I/O请求，您必须为每个请求建立个别的事件物件，在每个请求的OVERLAPPED结构中初始化hEvent成员然后呼叫ReadFile或WriteFile。当您到达程序代码中必须与I/O请求完成同时发生的位置时，简单地呼叫WaitForMultipleObjects并传入与每个未完成I/O请求的OVERLAPPED结构有关之事件handles。由于这个方案，您可以容易且可*地同时执行多重的非同步设备I/O操作以及使用相同的设备物件。以下的程序代码说明了这个方法：

HANDLE hfile = CreateFile(..., FILE_FLAG_OVERLAPPED, ...); 
BYTE bBuffer[10];
OVERLAPPED oRead = { 0 };
oRead.Offset = 0;
oRead.hEvent = CreateEvent(...);
ReadFile(hfile, bBuffer, 10, NULL, &oRead);
OVERLAPPED oWrite = { 0 };
oWrite.Offset = 10;
oWrite.hEvent = CreateEvent(...);
WriteFile(hfile, "Jeff", 5, NULL, &oWrite);
.
.
.
HANDLE h[2];
h[0] = oRead.hEvent;
h[1] = oWrite.hEvent;
DWORD dw = WaitForMultipleObjects(2, h, FALSE, INFINITE);
switch (dw - WAIT__OBJECT_0) {
 case 0: // 读取完成
  break;
 case 1: // 写入完成
  break;
}

这个程序代码有点不自然且不完全是您在真实的应用程序中所要做的，但它阐明了我的论点。一个典型的真实应用程序会有一个等待I/O请求完成的回圈。当每个请求完成，线程会执行被要求的任务、伫列另一个非同步I/O请求以及循环回圈，以及等待更多的I/O请求完成。

GetOverlappedResult
　

回想当初Microsoft不为OVERLAPPED结构的Internal及InternalHigh成员提供文件，意味着它必须提供另一个能让您知道在I/O行程期间有多少位元组已被转移以及获得I/O错误程序代码的方式。为了使您可得到这个资讯，Microsoft建立了这个GetOverlappedResult函数：

BOOL GetOverlappedResult(
 HANDLE hfile,
 OVERLAPPED* pOverlapped,
 PDWORD pdwNumBytes,
 BOOL fWait);

如今Microsoft为Internal及InternalHigh成员提供了文件，因此GetOverlappedResult函数即变得不是很有帮助。然而，当我第一次学习非同步I/O时，决定将这个函数做逆向工程以使我头脑里的观念变得稳固。以下的程序代码显示出内部如何实作GetOverlappedResult之方法：

BOOL GetOverlappedResult(
 HANDLE hfile,
 OVERLAPPED* po,
 PDWORD pdwNumBytes,
 BOOL fWait) {
 if (po->Internal == STATUS_PENDING) {
  DWORD dwWaitRet = WAIT_TIMEOUT;
  if (fWait) {
   // 等待I/O完成
   dwWaitRet = WaitForSingleObject(
    (po->hEvent != NULL) ? po->hEvent : hfile, INFINITE);
  }
  if (dwWaitRet == WAIT_TIMEOUT) {
   // I/O未完成而且我们不可以等待
   SetLastError(ERROR_IO_INCOMPLETE);
   return(FALSE);
  }
  if (dwWaitRet != WAIT_OBJECT_0) {
   // 呼叫WaitForSingleObject错误
   return(FALSE);
  }
 }
 // I/O完成：传回转移位元组的数量
 *pdwNumBytes = po->InternalHigh;
 if (SUCCEEDED(po->Internal)) {

  return(TRUE);   // No I/O error
 }
 // 将最后的错误设定为I/O错误
 SetLastError(po->Internal);
 return(FALSE);
}

可警告的I/O
　

第叁个可以用来接收I/O完成通知的方法是呼叫可警告的I/O。首先，对想要创造高效能、可伸缩性应用程序的开发人员来说，Microsoft侦查可警告的I/O作为绝对适当的机制。但是当开发人员开始使用可警告的I/O后，他们会很快地了解到它并没有实践这个承诺。

我对可警告的I/O已经了解得很彻底，而且会是第一个跟您说可警告的I/O糟透了的人，您应该避免使用它。然而，为了使可警告的I/O能够工作，我发现Microsoft在操作系统中加进了一些非常有帮助且有价值的基础建设。当您阅读这节时，请集中精神于适当的基础建设上，并且不要陷入I/O的泥沼。

无论线程何时被建立，系统也会建立一个与线程有关的伫列。这个伫列被称为非同步程序呼叫（Asynchronous Procedure Call, APC）伫列。当发布一个I/O请求时，您可以命令设备驱动程序附加一个入口到呼叫线程的APC伫列中。为了使完成的I/O通知被伫列到线程的APC伫列，可以呼叫ReadFileEx及WriteFileEx函数：

BOOL ReadFileEx(
 HANDLE hfile,
 PVOID pvBuffer,
 DWORD nNumBytesToRead,
 OVERLAPPED* pOverlapped,
 LPOVERLAPPED_COMPLETION_ROUTINE pfnCompletionRoutine);
BOOL WriteFileEx(
 HANDLE hfile,
 CONST VOID *pvBuffer,
 DWORD nNumBytesToWrite,
 OVERLAPPED* pOverlapped,
 LPOVERLAPPED_COMPLETION_ROUTINE pfnCompletionRoutine);

就像ReadFile及WriteFile，ReadFileEx及WriteFileEx发布I/O请求到某个设备驱动程序后，函数立即返回。ReadFileEx及WriteFileEx有与ReadFile和WriteFile函数相同的参数，其中有两个例外。第一，*Ex函数没有传递指标给填满转移位元组数量的DWORD；这个资讯只能经由回呼函数而被撷取。第二，*Ex函数需要您传递回呼函数的位址，称为完成例行程序。这个例行程序必须有以下的原型：

VOID WINAPI CompletionRoutine(
 DWORD dwError,
 DWORD dwNumBytes,
 OVERLAPPED* po);

当您与ReadFileEx及WriteFileEx一起发布非同步的I/O请求时，函数会传递这个函数的位址到设备驱动程序。当设备驱动程序完成I/O请求后，它会在发布线程的APC伫列里附加一个入口（entry）。这个入口包含了用来初始化I/O请求之完成例行程序的位址以及OVERLAPPED结构的位址。

说明

顺便一提，当某个可警告的I/O被完成时，设备驱动程序将不试图通知事件物件。事实上，设备一点也没有参考到OVERLAPPED结构的hEvent成员。因此，如果您喜欢的话，可以为您自己的目的而使用hEvent成员。

当线程为可警告的状态时，系统会检查它的APC伫列以及伫列中的每个入口，系统呼叫完成函数并传递I/O错误程序代码、转移位元组的数量以及OVERLAPPED结构的位址给它。请注意，错误程序代码及转移位元组的数量也可以在OVERLAPPED结构的Internal及InternalHigh成员中找到。（如前所述，Microsoft最初并不想为此提供文件，所以将它们当作参数传递给函数）。

我们不久将回到这里完成例行程序函数。现在让我们先看看系统如何处理非同步的I/O请求。以下的程序代码会伫列叁个不同的非同步操作：

hfile = CreateFile(..., FILE_FLAG_OVERLAPPED, ...); 
ReadFileEx(hfile, ...); // 执行第一个ReadFileEx
WriteFileEx(hfile, ...); // 执行第一个WriteFileEx
ReadFileEx(hfile, ...); // 执行第二个ReadFileEx
SomeFunc();

假如呼叫SomeFunc占用了一些执行时间，系统会在SomeFunc返回之前完成这叁个操作。当线程正在执行SomeFunc函数时，设备驱动程序会附加完成的I/O入口到线程的APC伫列中。APC伫列可能看起来有点像这个：

第一个WriteFileEx完成
第二个ReadFileEx完成
第一个ReadFileEx完成

APC伫列由系统内部维持。您亦可从清单中注意到系统可以使用任何顺序来执行伫列中的I/O请求，所以最后发布的I/O请求可能会最先完成，反之亦然。在线程之APC伫列中的每个入口包含收回函数的位址以及被传递到这个函数的值。

当I/O请求完成时，它们只简单地被伫列到线程的APC伫列中－即收回例行程序不会立即被呼叫，因为线程可能忙于作其他事情而不能被中断。为了处理线程之APC伫列中的入口，线程必须把它自己加进可警告的状态。这意味着线程已经达到执行中的位置，在那里它可以处理中断。Windows提供五个可以将线程加进可警告状态的函数：