由于迟到，我轻快地穿过登机通道，走进候机楼。我向窗外看了一眼，确认了航空公司杂志上的地图显示的情况，这让我松了一口气:我的转机，虽然严格来说在另一个航站楼，但实际上很近。我从这里就能看到它，尽管我和它隔着大约40码，隔着两层玻璃。但当我朝那个方向匆匆走去时，我意识到，从一个终点站到另一个终点站，只能坐某种类似有轨电车的东西;你不经过安检就走不过去。我恼怒地叹了口气，加快脚步，走过六个大门，来到有轨电车站。当我意识到这是一辆沿着一个方向绕行的有轨电车时。如果我运气好的话，我的工作会是第一站。我运气不好;电车向相反的方向行驶，所以我的站是最后一站。 Aligning all my chi to will the tram faster, I got to my stop, dashed out the door, skipped steps down the escalator, and vaulted towards the gate. Just in time. In 20 minutes I had managed to travel a net 40 yards.
有许多用于广泛旅行、连接或通信的机制，当不需要完整的机制时，它们就会受到影响。在使用多处理器的计算环境中，需要进程间通信(IPC)来确保所有进程能够相互通信必要的状态和数据。出于通用性的考虑，大多数这样的协议都需要考虑到处理器可能位于不同的芯片或盒子中，甚至不同的城市。用于此目的的协议类型包括TCP/IP、TIPC等。通用协议必须做出以下几个假设:
- 处理器之间的连接可能会失败，特别是当“云”参与长距离传输消息时。
- 系统运行过程中，节点间的互联关系可能会发生变化。
- 在系统运行过程中，任务和工作负载可能会发生变化。
- 处理器之间的带宽有限。
- 与确保正确处理上述问题相比，内存使用和性能并不重要。
像TCP/IP这样的协议充满了必要的需求，以确保断开的连接、拓扑重新映射和任务重新分配能够在带宽有限的情况下可靠地适应。
然而，在嵌入式多核应用程序中，情况几乎完全相反:物理连接通常只会由于灾难性的芯片故障而中断;拓扑和工作负载通常是静态的;带宽高;内存和性能是有限而宝贵的资源。例如，如果试图使用TCP/IP来执行多核IPC，那么处理永远不会发生的事件所需要的开销绝对会使系统不堪重负。这相当于要求建立一个华盛顿特区的地铁系统，以满足一个三个街区平方的中西部小镇的交通需求。这种情况迫切需要一种更适合多核提供的极其紧密耦合安排的协议。
多核协会就是为了解决这些问题而成立的，第一个积极进行的项目是开发适合嵌入式多核的IPC协议。其理念是构建一个基本协议，不需要花哨的机制，但允许在其之上构建更复杂的功能。这些努力的结果最近被批准为多核通信API (MCAPI)的第一个版本，该版本将于5月公开提供下载。MCAPI旨在提供一种简单的低开销方法，允许多核处理器中的核心相互通信。实现将提供运行时MCAPI服务，允许应用程序开发人员简单地使用API来访问这些服务。
使用API，您可以根据节点和端点定义多核拓扑。该排列是在编译时定义的，并且是静态的，因此协议中没有名称服务或发现。节点本质上是一个独立的线程;它可以是进程、核心、特定线程或任何其他本质上有自己的程序计数器的元素。最终，通信发生在节点之间。节点如此通用的事实意味着使用MCAPI的应用程序可以很容易地在不同的系统之间移植;在一个系统中，两个节点可能在一个物理核心中执行，而在另一个系统中，它们可能在不同的核心上执行。MCAPI实现处理这些差异;应用程序只知道它正在向另一个节点发送消息，而不管该节点的物理位置。
端点为与单个节点之间的各种类型的通信提供了更大的粒度。每个端点都与一个节点相关联，并可以被赋予优先级和缓冲区大小等属性。一个节点可以有多个端点;例如，可能有一对低优先级端点分别用于发送和接收，以及一对高优先级端点。一个特定的端点由它的节点ID和端点ID引用;这类似于指定IP地址和端口号，只不过端点是在编译时解析的。
MCAPI允许您以三种方式之一进行通信:无连接、分组和标量。无连接通信用于传递可能不频繁且离散的消息。它们带来了更高的开销，因为它们必须指定端点和缓冲区信息，并且必须在发送消息时计算出从开始到结束的路径。这就像个人发送联邦快递包裹;你必须手动填写运输信息，并弄清楚如何付款。
对于更频繁的通信，您可以通过设置通道来减少开销;包模式和标量模式使用通道。通过指定发送和接收端点，只需定义一次通道。一旦建立了通道，端点和缓冲区特征就已知了，因此在报头中不需要这些信息。路由也是在创建通道时计算出来的，因此在发送消息时不需要发现路由。这就像有一个联邦快递账户和预先打印的运输标签，所以你不必为每一次运输做所有的工作。车辆只能朝一个方向行驶;对于双工通信，需要创建两个相反方向的通道。对于要创建的通道，两个端点必须兼容;这在哲学上意味着像优先级这样的东西需要是相同的，但在实践中，目前还没有严格的兼容性定义，这个测试留给了MCAPI实现。
包模式允许以先进先出的方式为接收者传递任意大小的消息。标量模式允许传递固定大小的单个数据块，从而消除了头的需要。虽然在初始化和终止时分别设置和拆除通道可能很方便，但没有这样的需求;它们可以在任何时候被创造和毁灭。
目前，考虑到要保持简单，所有消息传递模式都是单播的——一个源到一个目的地。可以在MCAPI实现之上编写额外的代码，以提供多播(一个源到多个特定目的地)或广播(一个源到所有可能的目的地)。这允许从基本协议本身消除此类行为的开销，仅在系统中真正需要时才使用。对多播消息的显式API支持正在考虑将来的修订。
当然，您必须有空间来存储发送和接收的消息。该API允许您管理保存发送和接收数据所需的缓冲区和队列。消息缓冲区由发送应用程序分配;通道缓冲区由MCAPI服务分配。MCAPI将消息或包内容从发送缓冲区复制到目标缓冲区。通信中所需的任何报头都将由MCAPI封送，但消息的有效负载由应用程序封送。零拷贝操作，即只发送一个指向消息或包的指针(假定在共享内存中)，并不是由API显式提供的，但将来可能会考虑它。同时，它可以在MCAPI之上的一层中实现。
您可以在阻塞或非阻塞的基础上发送和接收消息。阻塞操作意味着，例如，如果正在发送一个64字节的缓冲区，当在代码中执行send指令时，下面的指令将不会执行，直到所有64字节都发送完毕。发送调用在发送完成时解除阻塞，而不是在相应的接收操作完成时解除阻塞。对于非阻塞调用，只要发送操作开始，代码执行就会继续到下一条指令。提供API调用来测试或等待非阻塞操作的完成，允许在某些东西挂起时超时。
MCAPI不提供任何显式的消息传递确认。事实上，成功的发送操作仅意味着数据成功发送，而不是成功接收。这是因为返回的成功代码只有调用进程才能看到。所以如果进程A发送了数据，那么只要数据发送出去，进程A就会看到它成功了。但是，进程B接收数据，并且可能成功接收，也可能不成功。进程B从自己的接收调用中看到成功代码;进程A没有。因此，仅仅因为从进程a发送成功并不意味着数据被正确接收。事实上，由于缺少节点或断开连接而导致的接收失败不被视为发送失败，而是接收失败，并且只有接收节点(如果存在的话)才知道它。如果接收节点在其队列中的所有数据被消耗之前断开连接或销毁，则包或数据可能丢失，并且发送方不会收到丢失通知。 So in a sense, messages are being tossed over the wall. If that’s a problem, it is possible to layer an acknowledgment mechanism above MCAPI to communicate complete end-to-end success. In the most conservative case, a sending process could issue a send instruction (blocking or non-blocking) followed by a blocking receive instruction intended to receive an acknowledgment.
许多协议都提供了流量控制机制，以确保通道的接收端能够跟上正在发送的数据。如果接收方开始不堪重负，那么发送方就会受到“反压力”，以减慢或暂停数据的发送，直到接收方能够赶上。这可能会变得非常复杂，必须考虑诸如缓冲空间、传输的数据量以及“减速!”请求返回给发送者。MCAPI没有这样的显式功能。发送端点可以在发送数据之前查询接收端点中可用的缓冲区空间量，但是任何更复杂的事情都必须在基本MCAPI实现的基础上进行分层。
关于MCAPI规范的进一步工作正在进行中。除了零拷贝传输和多播之外，调试、统计和状态调用也在考虑范围之内。在多核关联中，还需要在资源管理API上进行单独的工作，该API将允许管理共享和私有内存、分配和销毁区域、管理信号量以及注册和锁定通用资源等资源。在任务管理(创建、销毁、挂起、恢复、分配和设置属性)和调试功能方面预计会有单独的工作。
现在有了规范，就可以开始实施了。希望商业上可用的MCAPI包将允许程序员简单地使用API编写代码，并在构建中包含MCAPI库。api的执行应该是快速和节约资源的。从本质上讲，我们现在可以创造更多的步行空间，而不需要大量无用的基础设施投资。这样我就可以轻松地换乘附近的航班了。这个过程已经开始，我们将在后面的文章中看到一些早期的结果。与此同时，它为进一步的抽象提供了基础，这样，虽然实现是有效的，但应用程序程序员最终可以编程，甚至不必知道底层实现是紧密耦合还是松散耦合。稍后再详细讨论。
