我从MPI_任何来源收到消息到MPI Recv的顺序是什么，

我正在实现一个中心/服务器MPI应用程序。每个服务器都可能在等待某些数据时被占用，然后它们向集线器发送MPI。对我来说，让中心等待从任何来源进行Recv是相对简单的。集线器可能会忙于处理数据。我担心的是跳过其中一台服务器的数据。这种情况的可能性有多大：

• 服务器1和2不发送
• hub执行Recv并最终从服务器1获取数据
• 当集线器繁忙时，服务器1获取更多数据，另一个服务器是否发送数据
• 当hub进行下一次Recv时，它会获取较新的服务器1数据，而不是较旧的服务器2数据

我不需要保证发送的顺序是任何来源处理它们的顺序（尽管这会很好），但是如果我在实践中是新的，它将接近它们发送的顺序，我可以使用上面的方法。但是，如果我可能跳过其中一台服务器的数据，我需要实现更复杂的功能。我认为这是一种模式：

• 每个服务器都发送
• hub为每个服务器执行Irecv
• hub对所有服务器请求执行Waitany
• 一个服务器请求完成后，hub将对所有其他服务器请求进行测试
• 在所有已完成的Irecv中，hub选择最早的服务器数据（服务器数据中有计时标记）
• hub与它刚刚选择的服务器通信，让它开始一个新的发送，hub一个新的Irecv

这需要更复杂的代码，我的第一次努力在Waitany调用中失败，我发现调试起来很困难。我使用的是Python绑定mpi4py，因此我对正在使用的缓冲区的控制较少。

可以保证消息按发送顺序接收（非超车消息）。另见

---

但是，当从

任何源

接收时，以及当存在不同的发送者时，都会出现这种情况。因此，是的，如果应用程序需要，程序员有责任设计自己的公平系统。

感谢您为我指出这些。我读到有人说来自同一来源的信息是不超车的，但有一节关于公平的内容说标准是不公平的。这听起来像是来自不同来源的匹配消息可以相互超越？正确。根本无法保证在不同的流程之间进行排序。只是在同一个过程中。（我的第一条评论丢失了）你完全正确，我相应地更新了我的答案。我对此感到非常惊讶。我知道这是关于性能的，但它让任何源代码都毫无用处。不是真的。实际上，你从来没有真正看到过饥饿。每个实现最终都使用某种队列，在接收消息时添加消息。OP没有提到任何关于线程的内容，但我不知道这将如何改变事情。