CN104620233A

CN104620233A - 用于对cpu内的消息通道基础设施的多流访问的虚拟化通信套接字

Info

Publication number: CN104620233A
Application number: CN201380046815.7A
Authority: CN
Inventors: D·G·博科沃斯基; K·V·西斯特拉
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2012-10-09
Filing date: 2013-10-07
Publication date: 2015-05-13
Anticipated expiration: 2033-10-07
Also published as: US20140101355A1; US9092581B2; DE112013003924T5; WO2014058759A1; US9697059B2; DE112013003924B4; US20150254118A1; CN104620233B

Abstract

一种消息通道优化方法及系统允许对基于处理器的系统的CPU内的消息通道基础设施进行多流访问。用户(pcode)采用虚拟通道提交消息通道事务，其中消息通道驱动器“在幕后”处理事务。消息通道驱动器因此允许用户继续处理而无需阻止处理其他事务。每个事务都将被消息通道驱动器及时地或者在某个未来时间处理。该消息通道优化方法及系统用于涉及消息通道事务以及非消息通道事务的任务。

Description

用于对CPU内的消息通道基础设施的多流访问的虚拟化通信套接字

技术领域

本申请涉及多处理器系统、可移植机器代码以及消息通道事务处理。

背景

图1示出根据某些实施例的多处理器系统500的简化框图。多处理器系统500包括N个中央处理单元(CPU)150A、150B、150N(统称为“CPU150”)，其可耦合到N-1个专用总线，被称为快速通道互连(QPI)总线160A、160B、160N-1(统称为“QPI总线160”)。QPI总线160(专门为CPU设计)加速了CPU 150之间的通信。CPU还可耦合到一个或多个易失性存储器(未示出)。

多处理器系统500的特征还包括通过高达N条专用总线(被称为直接媒体接口(DMI)总线170A、170B......170N)耦合到CPU 150的高达N个外围控制器中枢(PCH)180A、180N(统称为“PCH 180”)。PCH 180在多处理器系统500的CPU 150以及一个或多个外围设备之间形成接口。PCH 180可包括显示器、输入/输出(I/O)控制、实时时钟以及其他功能并且可连接到集成显示器以及其他外围设备，诸如键盘、鼠标、非易失性存储设备等等。

对于多处理器系统500或基于单处理器的系统的处理器内的端点之间的通信而言，使用消息通道。该消息通道是用于这些通信的传输介质，并且可被认为是处理器内部的端点之间的“隧道”或“地道”类型。可存在许多消息通道端点，并且可将消息从任何端点发送到任何其他端点，其中，这些端点是处理器内的功能实体。可移植机器代码或pcode用于这些实体之间的通信，并且pcode具有其自身的用于向其他端点发送消息的端点。(没有端点向pcode发送自主消息，因为pcode端点接收到的唯一消息是对pcode发起的消息的响应。)功率管理请求(QMReq)消息使用QPI总线去往其他实体，这类似于消息通道，除QPI总线是外部总线/接口之外。相比之下，消息通道严格地位于处理器内部。

在基于CPU的系统内，诸如单处理器系统或图1的多处理器系统500，消息通道由许多分散的pcode流和函数使用。这些函数可用于对单核控制寄存器进行读和写、发布PMReq以及向其他平台实体(例如，其他CPU 150、PCH 180)发送消息。pcode非常频繁地使用消息通道，从每毫秒数百次到每毫秒数千次。

某些更新的多处理器系统被设计的方式为使得消息通道在不同的时刻(诸如在频率跃迁期间)变得阻塞。先前的多处理器系统没有这种问题，因为其消息通道接口总是完全功能性的。所以，先前项目中的pcode可以通过向消息通道发送事务并且在密封环中等待事务完成，来以“阻止”的方式使用消息通道。

对于更新的多处理器系统，在消息通道上使用“阻止”事务被认为是不可接受的，因为阻止事务可潜在地锁定pcode持续若干毫秒。因此，阻止事务导致其他(非消息通道相关的)功能的更高延迟并且影响CPU的性能。此外，存在锁死的风险，因为消息通道由等待通过边带接口来自pcode的某个东西的某个功能阻止，但是pcode被阻止，等待消息通道事务完成。

此外，PMreq消息要求对PMReq引擎(PME)中的单个缓冲器的使用的仲裁。PMreq消息通过消息通道到达PME，并且然后通过QPI总线160到达另一个CPU 150(或者通过DMI总线170到PCH 180)。作为PMreq协议正确性的一部分，PME将等待来自另一个CPU/PCH的完成(CMP)并且将保持PMreq缓冲器锁定，直至实际接收到完成。在这种情况下，如果使用阻止消息通道事务，pcode将被锁定持续PMreq/CMP交换的整个往返持续时间。另一个CPU上可存在延迟(由于频率变化等等)，其进一步延长锁死的持续时间。

因此，存在对克服现有技术的缺点的解决方案的持续需要。

附图简要描述

当结合附图时，前述方面和本发明的许多伴随优势将变得更加容易认识到，正如通过参照以下详细描述更好地理解到的那样，其中，贯穿各种视图，相同的参考标号指代相同的部件，除非另外指明。

图1示出根据某些实施例的多处理器系统的简化框图；

图2是根据某些实施例的消息通道优化方法和系统的简化框图；

图3是示出根据某些实施例的两个任务的任务流的流程图；

图4是示出根据某些实施例的与图3中的任务相同的两个任务的任务流的流程图，这次使用图2的方法和系统；

图5是根据某些实施例的如由图2的消息通道优化方法和系统处理的消息通道发送操作之后的流程图；以及

图6是根据某些实施例的如由图2的消息通道优化方法和系统处理的消息通道读取操作之后的流程图。

详细描述

根据在此描述的实施例，公开了用于允许对基于处理器的系统的CPU内的消息通道基础设施的多流访问的虚拟消息通道和驱动器。为使用消息通道的每个pcode流指派虚拟通道标识符。具有虚拟通道标识符的每个流可注册回调地址并且可提交一个消息通道事务用于处理。事务都将被消息通道驱动器及时地或者在某个未来时间处理。

在以下详细描述中，参考通过说明示出可在其中实践在此描述的主题的具体实施例的附图。然而，应当理解的是当阅读本公开时，其他实施例将对本领域普通技术人员变得明显。因此，以下详细描述不应被解释为限制性的意义，因为主题的范围由权利要求书限定。

图2示出根据某些实施例的消息通道优化方法100或优化方法100的简化框图。优化方法100采用用于允许对基于处理器的系统的消息通道基础设施的多流访问的虚拟化通信套接字(socket)。优化方法100使用消息通道驱动器50在虚拟通道70A、70B、...、70K(统称为“虚拟通道70”)与用于基于处理器的系统的处理器内的端点之间的通信的物理消息通道20之间形成接口。

在某些实施例中，优化方法100通过使用虚拟消息通道70而不是阻止消息通道50的使用，解决了在背景部分描述的针对诸如图1的多处理器系统500的系统的问题。尽管优化方法100解决了在多处理器系统中发现的问题，该方法还可用在单处理器系统中。

用户(标记为用户130A、用户230B、用户K 30K(统称为“用户30”))贯穿多处理器系统表示pcode流的部分。由应用编程接口(API)和帮助函数组成的工具80可用于消息通道驱动器50和用户30。

在某些实施例中，方法100为使用消息通道20的每个用户(pcode流)30指派虚拟通道标识符(VCID)60。虚拟通道标识符60A、60B、...、60K(统称为“VCID 60”)可分别用于每个用户30A、30B、...、30K。具有VCID 60的每个pcode流30还能够注册回调地址。在图2中分别针对用户1、2、…、K特别示出回调地址40A、40B、...、40K(统称为“回调地址40”)。每个用户30的回调地址40在处理该用户的消息通道事务之后，允许消息通道驱动器50在适当的地址返回pcode流。具有VCID 60的每个用户30可提交一个消息通道事务用于处理。

在某些实施例，每个用户30A、30B、...、30K包括对应的缓冲器90A、90B、...、90K(统称为“缓冲器90”)。缓冲器90是有待在消息事务之后返回的消息通道数据的临时存储。在某些实施例中，当处理消息通道事务时，消息通道驱动器50检索返回缓冲器90的数据。

进一步地，在某些实施例中，消息通道驱动器50包括队列110以便跟踪等待处理的事务。当处理后续事务时，消息通道驱动器将从队列110检索该事务。在某些实施例中，队列110是先进先出队列。

图2的用户30被假定是发生消息通道事务的那些pcode流。其他pcode流可不参与消息通道事务。因此，在某些实施例中，不为这种pcode流指派VCID 60。无论如何，如以下所示，在某些实施例中，用于消息通道事务和非消息通道事务的pcode流从在此描述的优化方法100受益。

在某些实施例，消息通道事务将被消息通道驱动器50及时地或者在某个未来时间处理。消息通道驱动器50注册致使基于处理器的系统中的核心(kernel)当消息通道事务已经完成时运行回调函数的事件。当其回调函数运行时，提交事务的用户(pcode流)30被通知完成，允许用户在完成之后采取任何进一步所期望的动作。

图3是示出根据某些实施例的其中消息通道20顺序地处理两个任务的方法200的流程图。图3的操作200在基于单处理器的系统中或者在多处理器系统中执行，诸如图1的系统500。方法200的特征包括在每个步骤的左侧用红色标识出的时间段内执行的多个步骤。有待执行两个任务，任务1和任务2。这些任务是早先提及的pcode流30的一部分，其中，pcode流在基于单处理器的系统中或者在多处理器系统中发布消息通道事务。任务1涉及消息通道事务，而任务2不涉及。

针对那些涉及消息通道事务的任务，任务被划分为1)准备数据、2)消息通道上的事务、3)处理消息通道的结果、以及4)可不与消息通道相关的其他数据处理。

在第一时间段(时间段1)，任务1(第一pcode流(用户)30)开始(框200)。在时间段2的数据准备(框202)之后，pcode流30在时间段3发布消息通道事务(框204)，因此调用消息通道20。第一pcode流30等待事务完成(框206)，而没有进一步的处理发生。在本示例中，存在100个时间单位的超时时段，并且这个整个时段内pcode流30被阻止，称为阻止事务。在时间段103，对消息通道的结果进行处理(框208)，并且任务1完成(框210)。

pcode流30进一步包括第二任务，任务2。任务2在时间段106开始(框212)。数据处理在时间段107发生(框214)，并且任务2由时间段108完成(框216)，其中，有待在任务2完成之后执行附加任务。

相比之下，图4的特征包括根据某些实施例顺序地在基于单处理器的系统上或者在多处理器系统(诸如图1的系统500)上执行相同的两个任务，这次使用图2的消息通道优化方法100。然而，第一任务(任务1)被分成被分别处理的两部分，任务1a和任务1b。

最初，以与在图3中处理任务1相似的方式处理第一任务的第一部分(任务1a)。在第一时间段(时间段1)，任务1(第一pcode流30)开始(框300)。在时间段2的数据准备之后(框302)，pcode流30在时间段3发布消息通道事务(框304)，因此调用消息通道20。在本示例中，不是使第一pcode流30等待事务完成(如在图3的框206中)，消息通道驱动器50在时间段4对消息通道事务进行排队(框306)。任务1a(任务1的第一部分)在时间段5完成(框308)。

如同方法200(图3)，在方法300中(图4)，pcode流30进一步包括第二任务(任务2)。任务2在时间段6开始(框310)。数据处理在时间段7发生(框312)，并且任务2由时间段8完成(框314)，其中，有待在任务2完成之后执行附加任务。注意，在图3中，任务2在时间段108完成，而在当前示例中，任务2在时间段8以快一百个时间单位完成。

返回第一任务的处理，当发布消息通道事务时(框304)，事务被处理，正如图3所示。并且，正如图3所示，事务使用有待处理的100个时间段。在图4中，事务处理尚未中断或改变，而是，事务由消息通道驱动器50排队，允许事务1a处理完成，从而使得可处理下一个任务(任务2)。

同时，在某些实施例中，当在任务1a期间发起的消息通道事务完成时，在时间段103内生成硬件事件(框400)。消息通道驱动器50通过在时间段104内向任务1的第二部分(任务1b)的地址发布回调，对硬件事件做出响应(框402)。针对给定pcode流(用户)30的回调地址40包含该地址。任务1b在时间段105内开始(框404)。由于消息通道事务已完成，在时间段106内执行结果处理(框406)，并且在时间段107内任务1b结束(框407)。

将图3的操作200与图4的优化操作300、400进行比较是有启发性的。在图3中，在108个时间段内处理两个pcode流任务(任务1和任务2)。在图4中，在107个时间段内处理相同的两个pcode流任务(任务1和任务2)，其中第一任务进一步被细分为任务1a和1b，改进了一个时间段。此外，然而，存在进一步的机会在任务2完成之后顺序地处理附加任务，其中95个时间段在时间段8和时间段103之间可供使用。并且，可在这些95个时间段期间处理发布消息通道事务的每个任务(诸如任务1)或者未发布消息通道事务的任务(诸如任务2)。因此，图4的操作300、400提供高效地处理消息通道事务的附加机会，而无需阻止一个或多个事务。

此外，在某些实施例中，任务2事务的处理在方法300中比在方法200开始得早得多。并且，通过能够在95个附加时间段内顺序地处理更多任务，这些循环可为系统处理事务提供功能益处。在某些实施例中，pcode每毫秒发布数百个消息通道事务，从而使用这些循环的潜在益处会是显著的。

回顾消息通道驱动器50和用户30都使用工具80来辅助执行优化方法100。图5示出在某些实施例中优化方法100所使用的工具80。存在被分类为应用编程接口(API)函数的四个函数72、74、76和78以及被认为是帮助函数的两个函数82和84。功能上，用户30与驱动器50接口连接(经由API函数72、74、76、78)，并且驱动器与处理器接口连接。因此，API函数使得用户能够经由驱动器50访问处理器。

在某些实施例中，第一API函数72(is_virtual_message_channel_busy，虚拟消息通道是否忙碌)使得用户30能够确定其虚拟通道是忙碌还是空闲。用户30的VCID 60被提供作为到这个函数72的输入。回顾，基于VCID 60，虚拟通道70被指派给用户30。如果用户30在其虚拟通道70上感测到请求，直至第一消息已经被处理才能发送另一个请求。因此，在继续第二消息之前，用户30使用API函数72确定其虚拟消息通道70是否不忙碌。此外，如果消息通道请求是返回数据的请求，用户30使用API函数72确定该请求是否已完成，因此使得用户能够检索所返回的数据。API函数72因此基本上是用户30和消息通道驱动器50之间的握手机制。API函数72为用户30返回针对VCID 60所指定的虚拟消息通道70的运行/忙碌位。

在某些实施例中，第二API函数74(message_channel_virtual_read，消息通道虚拟读取)返回由输入(VCID 60)指定的虚拟消息通道的内容。在某些实施例中，64位消息通道有效负载结果由API函数74返回。消息通道驱动器50向与用户30相关联的缓冲器90返回读取信息。因此，当调用此读取函数74时，用户30将读取缓冲器90的内容。

在某些实施例中，第三API函数76(message_channel_virtual_send，消息通道虚拟发送)是用户30通过其使用虚拟消息通道70在消息通道20上发送消息的手段。回顾，消息通道20由处理器的端点之间的许多分离的pcode流和函数使用，以便诸如对单核控制寄存器进行读和写、发布功率管理请求(PMReq)、以及向其他平台实体(例如，多处理器系统500内的其他CPU 150、PCH180)发送消息。再次，用户30的VCID 60被提供作为到这个函数76的输入。一旦消息在虚拟消息通道70上，消息通道驱动器50能够在消息通道30上处理消息。

在某些实施例中，第四API函数78(message_channel_virtual_send_PMreq，消息通道虚拟发送PMreq)是处理PMreq传输的第三API函数76的特殊版本。如其他API函数一样，用户30的VCID 60被提供作为到这个函数78的输入。PMreq(功率管理请求的简称)是由在CPU之间互连的QPI总线所使用的特殊事务类型(图1)。

在某些实施例中，虽然用户30和消息通道驱动器50都使用上述API函数，仅驱动器50使用帮助函数82和84。帮助函数允许数据在虚拟通道70和物理消息通道20之间的流畅移动。第一帮助函数(message_channel_send_to_physical 82，消息通道向物理通道发送82)使得消息通道驱动器50能够向物理消息通道20发送数据。第二帮助函数(message_channel_poll_physical_with_timeout 84，带超时的消息通道轮询物理通道84)使得消息通道驱动器50能够针对操作是否完成轮询物理消息通道并且包括超时。

在某些实施例中，消息通道驱动器50注册致使基于单处理器的系统或多处理器系统内的核心在消息通道事务已经完成时运行回调函数的事件。该事件是指示消息通道20不再忙碌的硬件事件，诸如中断，其意味着驱动器放入消息通道内的最后事情已完成。

在某些实施例中，代表用户(pcode流)30，消息通道驱动器50将消息从用户的所指派的虚拟通道70放到消息通道20中。消息通道驱动器50理解该消息是否要返回数据。当有待返回数据时，消息通道驱动器50检索该数据并且将其放到专用于用户30的缓冲器90中。在驱动器50的检索之后，用户30采用API读取函数74来检索缓冲器90的内容。

一旦代表一个用户对消息通道事务的处理已完成，消息通道驱动器50可代表另一个用户30进行到将另一个虚拟通道70“连接到”消息通道20。

图6和图7是示出根据某些实施例的消息通道优化方法100分别处理发送操作和读取操作的操作的流程图。图6示出基于单处理器系统或者多处理器系统(诸如图1的多处理器系统500)的用户30之一的发送操作，而图7示出读取操作。

首先，图6描述发送操作。在某些实施例中，在用户30可在消息通道20上发布任何事务之前，用户指派的虚拟消息通道70必须是可供使用的。因此，用户发布第一API函数72以便确定虚拟消息通道70是否是可供使用的(框102)。一旦是可供使用的，用户30发布API发送函数，通用API发送函数76或者是专用API发送PMreq函数78(框104)。用户30还注册消息通道驱动器50将用于向用户的预定地址进行返回(框106)的回调地址(框106)在这一点，消息通道(发送)事务由消息通道驱动器50排队(框108)。这使得用户30可以继续进行其他事务处理。

当发送事务由用户30发布时，消息通道20可能不可供使用。典型的多处理器系统的pcode非常频繁地使用消息通道，从每毫秒上百次到上千次。因此，直至消息通道20不忙碌，才处理发送事务(框110)。一旦消息通道20是可供使用的，硬件事件(诸如中断)将通知消息通道驱动器50消息通道是可供使用的。

然而，消息通道驱动器50为许多不同用户处理虚拟消息通道事务。一旦消息通道20是可供使用的并且一旦用户在消息通道驱动器的队列110的顶部，消息通道驱动器50将消息通道事务从用户的虚拟通道70发送至消息通道20(框112)。一旦在消息通道20，处理消息通道事务(框114)。消息通道驱动器50于是注册事件。该事件致使基于单处理器的系统或多处理器系统的核心(kernel)运行到用户30的回调地址40的回调函数(框116)。用户30因此能够完成发送事务(框118)。

图7示出类似的操作，这时用户30正在向消息通道20发送读取操作。再次，用户首先确保虚拟通道70是可供使用的(框152)。一旦是可供使用的，用户30向其虚拟消息通道70发布API读取函数74(框154)。用户还注册其回调地址(框156)，从而使得一旦消息通道事务完成，消息通道驱动器50将能够返回到用户pcode流30。消息通道驱动器50对事务进行排队(框158)。

一旦消息通道20是可供使用的(框160)并且一旦用户在消息通道驱动器的队列110的顶部，消息通道驱动器50将消息通道事务从用户的虚拟通道70发送至消息通道20(框162)。一旦在消息通道20，处理消息通道事务(框164)。消息通道驱动器50于是注册事件。这致使基于单处理器的系统或多处理器系统的核心(kernel)运行到用户30的回调地址40的回调函数(框166)。由于事务是读取事务，消息通道驱动器50将读取的内容放入用户30的缓冲器90中。用户30因此检索缓冲器90的内容(框168)并且完成读取事务(框170)。

消息通道优化方法及系统100因此允许对基于单处理器的系统或多处理器系统的CPU内的消息通道基础设施进行多流访问。用户采用虚拟通道提交消息通道事务，其中消息通道驱动器“在幕后”处理事务。每个事务都将被消息通道驱动器及时地或者在某个未来时间处理。在某些实施例中，涉及消息通道事务以及非消息通道事务的任务被更高效地处理。

尽管已经针对有限数量的实施例描述了本申请，本领域技术人员将认识到从其延伸的多种修改和变化。旨在所附权利要求书涵盖落入本发明的真实精神和范围中的所有这种修改和变化。

Claims

1.一种包括代码的非瞬态计算机可读介质，当被执行时，所述代码致使机器执行以下操作：

向经指派的虚拟消息通道发布消息通道事务，其中所述消息通道事务由消息通道驱动器排队；

对所述消息通道事务进行排队；

处理所述消息通道事务之后的后续事务而无需等待所述消息通道事务完成；

接收用于指示物理消息通道可供使用的硬件事件；以及

响应于接收到所述硬件事件，将所述消息通道事务从所指派的虚拟消息通道转移到所述物理消息通道。

2.如权利要求1所述的非瞬态计算机可读介质，当被执行时，所述代码致使所述机器进一步执行以下操作：

通过虚拟消息通道标识符指示所述多个虚拟消息通道中的哪个通道可供使用。

3.如权利要求1所述的非瞬态计算机可读介质，当被执行时，所述代码致使所述机器进一步执行以下操作：

指示在将所述消息通道事务转移到所述物理消息通道之后要转移到的返回地址。

4.如权利要求1所述的非瞬态计算机可读介质，当被执行时，所述代码致使所述机器进一步执行以下操作：

从所述物理消息通道检索数据；以及

将所述数据存储在缓冲器中。

5.一种处理消息通道事务而无需执行阻止操作的方法，所述方法包括：

由用户向消息通道发布消息通道事务，其中所述用户包括由基于处理器的系统内的处理器执行的可移植机器代码(pcode)的一部分并且所述消息通道事务被接收到指派给所述用户的虚拟消息通道中；

由驱动器对所述消息通道事务进行排队，其中所述用户能够进一步处理pcode而无需等待所述消息通道事务完成；

由所述驱动器接收指示所述消息通道可供使用的硬件事件；

由所述驱动器将所述用户的所述消息通道事务从所述虚拟消息通道转移到所述消息通道，其中所述消息通道事务由所述消息通道携带到端点；

由所述驱动器使用所述用户提供的回调地址返回到所述用户pcode；以及

由所述用户完成所述消息通道事务的执行。

6.如权利要求5所述的方法，进一步包括：

由所述用户向所述驱动器发布函数，其中所述函数告知所述用户所述虚拟消息通道是否忙碌。

7.如权利要求5所述的方法，进一步包括：

由所述驱动器向所述处理器发布事件，其中所述事件致使核心对所述回调地址运行回调函数。

8.如权利要求5所述的方法，进一步包括：

由所述驱动器将消息通道事务结果存储在缓冲器中；以及

由所述用户从所述缓冲器检索结果。

9.一种在基于处理器的系统中处理两个任务的方法，所述两个任务作为由所述基于处理器的系统执行的可移植机器代码(pcode)的一部分执行，所述方法包括：

执行第一任务的数据准备部分，所述第一任务包括数据准备、发布消息通道事务以及结果处理；

向所述基于处理器的系统内的处理器发送函数，其中所述函数致使所述消息通道事务由消息通道驱动器排队；以及

执行第二任务，所述第二任务不包括消息通道事务，其中所述第二任务被执行，而不管所述第一任务的所述消息通道事务是否已完成；

其中，所述消息通道驱动器在接收到硬件事件时将所述消息通道事务从虚拟消息通道转移到消息通道，其中所述消息通道事务由所述消息通道携带到端点。

10.如权利要求9所述的方法，进一步包括：

执行所述第一任务的结果处理部分。

11.如权利要求9所述的方法，进一步包括：

向所述消息通道驱动器发送回调地址；

其中，所述消息通道驱动器在所述消息通道事务被执行之后调用所述回调地址。

12.一种设备，包括：

事务装置，用于向虚拟消息通道发起消息通道事务以及注册回调地址；

驱动器装置，用于由用户对所述消息通道事务进行排队以及响应于所述消息通道可供使用将消息从所述虚拟消息通道转移到所述消息通道；

通道装置，用于处理所述消息；

回调装置，用于致使所述驱动器装置注册事件以便致使核心对所述回调地址运行回调函数；以及

完成装置，用于完成所述消息通道事务。

13.如权利要求12所述的设备，进一步包括：

第一装置，用于确定所述虚拟消息通道是否忙碌；

所述驱动器装置用于指示当接收到所述第一装置时所述虚拟消息通道是否忙碌。

14.如权利要求13所述的设备，进一步包括：

第二装置，用于请求读取所述虚拟消息通道；

所述驱动器装置用于当接收到所述第二装置时返回所述虚拟消息通道的内容。

15.如权利要求14所述的设备，进一步包括：

第三装置，用于请求将存储在所述虚拟消息通道中的数据发送到所述消息通道；

所述驱动器装置用于当接收到所述第三装置时将所述数据从所述虚拟消息通道转移到所述消息通道。

16.如权利要求12所述的设备，进一步包括：

第四装置，用于将数据从所述虚拟消息通道转移到所述物理消息通道。

17.一种装置，包括：

处理逻辑，用于处理第一任务；

通道逻辑，用于响应于所述处理逻辑处理所述第一任务，发布第一消息通道事务；

消息通道驱动器逻辑，用于保持对所述第一消息通道事务的引用；

其中，所述处理逻辑进一步用于在所述第一消息通道事务完成之前开始处理第二任务；以及

其中，所述消息通道驱动器逻辑进一步用于在所述处理逻辑开始处理所述第二任务之后响应于与所述第一消息通道事务的完成相关联的事件，发起所述第一任务的后续处理。

18.如权利要求17所述的装置，进一步包括：

队列，用于保持对所述第一消息通道事务的引用。

19.如权利要求17所述的装置，进一步包括：

由所述消息通道驱动器使用的多个工具，所述多个工具包括：

忙碌函数，用于确定所述通道逻辑是可用还是忙碌；

读取函数，用于读取所述通道逻辑的内容；以及

发送函数，用于向所述通道逻辑发送数据。

20.如权利要求19所述的装置，所述多个工具进一步包括：

发送功率管理请求函数，用于向所述通道逻辑发送功率管理请求。