ACE技术论文集-第8章 异步事件多路分离和分派处理器
发布: 2008-6-13 14:40 | 作者: Prashant Jain and D | 来源: 转载 | 查看: 430次
当具有以下一项或多项条件时使用前摄器模式：
- 应用需要执行一个或多个不阻塞调用线程的异步操作；
- 当异步操作完成时应用必须被通知；
- 应用需要独立于它的I/O模型改变它的并发策略；
- 通过使依赖于应用的逻辑与应用无关的底层构造去耦合，应用将从中获益；
- 当使用多线程方法或反应式分派方法时，应用的执行将很低效，或是不能满足性能需求。
在图8-7中使用OMT表示法演示了前摄器模式的结构。
前摄器模式中的关键参与者包括：
前摄发起器（Proactive Initiator。Web服务器应用的主线程）：
- Proactive Initiator是应用中任何发起Asynchronous Operation（异步操作）的实体。它将Completion Handler和Completion Dispatcher登记到Asynchronous Operation Processor（异步操作处理器），此处理器在操作完成时通知前摄发起器。
完成处理器（Completion Handler。Acceptor和HTTP Handler）：
- 前摄器模式将应用所实现的Completion Handler接口用于Asynchronous Operation完成通知。
异步操作（Asynchronous Operation。Async_Read、Async_Write和Async_Accept方法）：
- Asynchronous Operation被用于代表应用执行请求（比如I/O和定时器操作）。当应用调用Asynchronous Operation时，操作的执行没有借用应用的线程控制。因此，从应用的角度来看，操作是被异步地执行的。当Asynchronous Operation完成时，Asynchronous Operation Processor将应用通知委托给Completion Dispatcher。
异步操作处理器（Asynchronous Operation Processor。操作系统）：
- Asynchronous Operation是由Asynchronous Operation Processor来运行直至完成的。该组件通常由OS实现。
完成分派器（Completion Dispatcher。Notification Queue）：
- Completion Dispatcher负责在Asynchronous Operation完成时回调应用的Completion Handler。当Asynchronous Operation Processor完成异步发起的操作时，Completion Dispatcher代表应用执行应用回调。
图8-7 前摄器模式中的参与者
有若干良好定义的步骤被用于所有Asynchronous Operation。在高水平的抽象上，应用异步地发起操作，并在操作完成时被通知。图8-8显示在模式参与者之间必定发生的下列交互：
- 前摄发起器发起操作：为执行异步操作，应用在Asynchronous Operation Processor上发起操作。例如，Web服务器可能要求OS在网络上使用特定的socket连接传输文件。要请求这样的操作，Web服务器必须指定要使用哪一个文件和网络连接。而且，Web服务器必须指定（1）当操作完成时通知哪一个Completion Handler，以及（2）一旦文件被传输，哪一个Completion Dispatcher应该执行回调。
- 异步操作处理器执行操作：当应用在Asynchronous Operation Processor上调用操作时，它相对于其他应用操作异步地运行这些操作。现代操作系统（比如Solaris和Windows NT）在内核中提供异步的I/O子系统。
- 异步操作处理器通知完成分派器：当操作完成时，Asynchronous Operation Processor取得在操作被发起时指定的Completion Handler和Completion Dispatcher。随后Asynchronous Operation Processor将Asynchronous Operation的结果和Completion Handler传递给Completion Dispatcher，以用于回调。例如，如果文件已被异步传输，Asynchronous Operation Processor可以报告完成状态（比如成功或失败），以及写入网络连接的字节数。
- 完成分派器通知应用：Completion Dispatcher在Completion Handler上调用完成挂钩，将由应用指定的任何完成数据传递给它。例如，如果异步读取完成，通常一个指向新到达数据的指针将会被传递给Completion Handler。
图8-8 前摄器模式的交互图
这一部分详述使用前摄器模式的效果。
前摄器模式提供以下好处：
增强事务分离：前摄器模式使应用无关的异步机制与应用特有的功能去耦合。应用无关的机制成为可复用组件，知道怎样多路分离与Asynchronous Operation相关联的完成事件，并分派适当的由Completion Handler定义的回调方法。同样地，应用特有的功能知道怎样执行特定类型的服务（比如HTTP处理）。
改善应用逻辑可移植性：通过允许接口独立于执行事件多路分离的底层OS调用而复用，它改善了应用的可移植性。这些系统调用检测并报告可能同时发生在多个事件源之上的事件。事件源可以是I/O端口、定时器、同步对象、信号，等等。在实时POSIX平台上，异步I/O函数由aio API族[9]提供。在Windows NT中，I/O完成端口和重叠式（overlapped）I/O被用于实现异步I/O[10]。
完成分派器封装了并发机制：使Completion Dispatcher与Asynchronous Operation Processor去耦合的一个好处是应用可以通过多种并发策略来配置Completion Dispatcher，而不会影响其他参与者。如8.7所讨论的，Completion Dispatcher可被配置使用包括单线程和线程池方案在内的若干并发策略。
线程策略被与并发策略去耦合：因为Asynchronous Operation Processor代表Proactive Initiator完成可能长时间运行的操作，应用不会被迫派生线程来增加并发。这使得应用可以独立于它的线程策略改变它的并发策略。例如，Web服务器可能只想每个CPU有一个线程，但又想同时服务更多数目的客户。
提高性能：多线程操作系统执行上下文切换，以在多个线程控制中轮换。虽然执行一次上下文切换的时间保持相当的恒定，如果OS上下文要切换到空闲线程的话，在大量线程间轮换的总时间可以显著地降低应用性能。例如，线程可以轮询OS以查看完成状态，而这是低效率的。通过只激活那些有事件要处理的合理的线程控制，前摄器模式能够避免上下文切换的代价。例如，如果没有待处理的GET请求，Web服务器不需要启用HTTP Handler。
应用同步的简化：只要Completion Handler不派生另外的线程控制，可以不考虑、或只考虑少许同步问题而编写应用逻辑。Completion Handler可被编写为就好像它们存在于一个传统的单线程环境中一样。例如，Web服务器的HTTP GET处理器可以通过Async Read操作（比如Windows NT TransmitFile函数[1]）来访问磁盘。
前摄器模式有以下缺点：
难以调试：以前摄器模式编写的应用可能难以调试，因为反向的控制流在构架基础结构和应用特有的处理器上的回调方法之间来回振荡。这增加了在调试器中对构架的运行时行为的“单步跟踪”的困难度，因为应用开发者可能不了解或不能获得构架的代码。这与试图调试使用LEX和YACC编写的编译器的词法分析器和解析器时所遇到的问题是类似的。在这些应用中，当线程控制是在用户定义的动作例程中时，调试是相当直接的。但是一旦线程控制返回到所生成的有限确定自动机（Deterministic Finite Automate，DFA）骨架时，就很难跟住程序逻辑了。
调度和控制未完成操作：Proactive Initiator可能没有对Asynchronous Operation的执行顺序的控制。因此，Asynchronous Operation Processor必须被小心设计，以支持Asynchronous Operation的优先级和取消处理。
前摄器模式可以通过许多方式实现。这一部分讨论实现前摄器模式所涉及的步骤。
实现前摄器模式的第一步是构建Asynchronous Operation Processor。该组件负责代表应用异步地执行操作。因此，它的两项主要责任是输出Asynchronous Operation API和实现Asynchronous Operation Engine以完成工作。
Asynchronous Operation Processor必须提供API、允许应用请求Asynchronous Operation。在设计这些API时有若干压力需要考虑：
可移植性：此API不应约束应用或它的Proactive Initiator使用特定的平台。
灵活性：常常，异步API可以为许多类型的操作共享。例如，异步I/O操作常常被用于在多种介质（比如网络和文件）上执行I/O。设计支持这样的复用的API可能是有益的。
回调：当操作被调用时，Proactive Initiator必须登记回调。实现回调的一种常用方法是让调用对象（客户）输出接口、让调用者知道（服务器）。因此，Proactive Initiator必须通知Asynchronous Operation Processor，当操作完成时，哪一个Completion Handler应被回调。
完成分派器：因为应用可以使用多个Completion Dispatcher，Proactive Initiator还必须指示由哪一个Completion Dispatcher来执行回调。
给定所有这些问题，考虑下面的用于异步读写的API。Asynch_Stream类是用于发起异步读写的工厂。一旦构造，可以使用此类来启动多个异步读写。当异步读取完成时，Asynch_Stream::Read_Result将通过Completion_Handler上的handler_read回调方法被回传给handler。类似地，当异步写入完成时，Asynch_Stream::Write_Result将通过Completion_Handler上的handler_write回调方法被回传给handler。
class Asynch_Stream
// = TITLE
// A Factory for initiating reads
// and writes asynchronously.
{
// Initializes the factory with information
// which will be used with each asynchronous
// call. is notified when the
// operation completes. The asynchronous
// operations are performed on the
// and the results of the operations are
// sent to the .
Asynch_Stream (Completion_Handler &handler,
HANDLE handle,
Completion_Dispatcher *);
// This starts off an asynchronous read.
// Upto will be read and
// stored in the .
int read (Message_Block &message_block,
u_long bytes_to_read,
const void *act = 0);
// This starts off an asynchronous write.
// Upto will be written
// from the .
int write (Message_Block &message_block,
u_long bytes_to_write,
const void *act = 0);
...
};