2.6.4 AM Ring示例
在上节的“Ping-Pong”示例中，通信仅发生在Request和对发送端的Reply上。该例子使用的是最简单的逻辑通信类型。然而，现实的应用通常至少需要使用“A-to-B-to-C”的通信模式，本节介绍的“Ring”示例（如代码清单2-4和代码清单2-5所示）即为这种通信类型的典型实现。与“Ping-Pong”示例一样，代码清单2-4和代码清单2-5分别替换了“Hello，World！”示例中的第19～21行和第32～34行代码。
本示例主要是从节点0开始依次按照升序发送消息，在最大编号的节点之后回到节点0形成一个多次传递的虚拟令牌环。由于每个节点必须从其前一个节点接收并发送给下一个节点，因此“Ping-Pong”示例的Request+Reply逻辑只适用于1个或2个节点。对于多个节点的计数需要使用不同的方法。具体而言，当节点接收到AM时，它必须推迟发送下个消息，直到控制返回到非应用程序代码部分。理解这个概念非常重要，因为“延迟执行”是许多“如何与活动消息进行X？”问题的解决方案。因此我们使得“Ring”示例具有更多的通用性而不是必要性。
本例有一个处理程序，此时希望能有一个在运行在main()上的代码检索排队信息前打印包括AM负载项消息的Medium AM。需要注意的是当在节点0上执行时，接收的参数在入队前是递增的，以保证环遍历能够最终结束。本例中的设想是以顺序遍历环的方式执行，因此需要将((mynode+1)%nodes)表达式作为第一个参数传递给Enqueue()。但是在实际应用中，下个消息的目的可能是处理程序参数和负载项的某种组合函数，以便能够实现更加复杂的任务。
首先重点分析下代码清单2-5中的main()函数逻辑，首先可以发现这里确定步长计数的逻辑与上节例子中的相同，然后构造了一个非常简单的节点特定消息。而实际的通信开始于节点0向环中的“next”节点发送的首个AM Request，如果运行在单个节点上，则负载“由0发送”且单个参数值为1。通过依次调用gasnet_AMPoll和Dequeue函数，所有节点进入轮询循环。如果没有到达，gasnet_AMPoll将以无阻塞方式执行AM，那么Dequeue函数的返回值可能为0，表示没有在排队的任务。但是当AM处理程序有排队的任务时，将向排队的目的节点发送新的AM Request（带有发送方标记的msg以及排队参数）。每个节点在接收到等于预期的步长计数参数消息后终止循环。此外，还有一些不常见的逻辑操作以防止节点0在完成时发送“额外”消息。
值得注意的是不同节点的输出可以重新排序，没有命令行参数的3个节点运行的输出结果如下所示。
