MPI_Isend 之后 MPI_Wait 的确切行为是什么？

Question

我已阅读所有 MPI 文档和教程以及与此相关的 Stack Overflow 问题，但我仍然不完全了解 MPI_Wait 在“完成” MPI_Isend 时的行为方式。我们可以简明扼要地概括一下吗？有吗

• A.对应 Isend 中使用的缓冲区可用时返回 再次（我认为是的，但这并不能告诉我我想要的一切 知道）。
• 乙。对应的 Recv 完成时返回（我认为不是 必然，但有时如果消息很大？）
• C.保证Recv在返回后的某个时间可以被接收进程完成

我问是因为我正在尝试实现一种非阻塞广播（因为 MPI_Ibcast 是 MPI 3 的东西，并且在我实际遇到的任何实现中似乎都不存在）。我目前在每个过程中遵循的顺序是这样的：

1. MPI_Isend 从每个进程到每个其他进程
2. 做一些其他的工作
3. MPI_Wait 表示所有的“完成”，无论这意味着什么
4. MPI_Recv所有消息

这在实践中似乎工作正常，但我不知道它是否保证可以工作，或者我是否很幸运，因为我的消息很小（它们每个只有一个 int，所以我怀疑它们会被 MPI 迅速洗牌到一些内部缓冲区或其他任何东西中）。我不知道如果消息更大，这是否会造成死锁（我担心在这种情况下并非所有 MPI_Waits 都会返回，因为有些可能会死锁等待 MPI_Recvs 在另一个进程上发生）。

如果不能保证这通常可以正常工作，那么至少可以保证对非常小的消息有效吗？或者这不一定是真的？我真的不确定我可以在这里指望什么。

如果这不能保证有效，那么如何实现非阻塞广播？也许有一些巧妙的顺序来执行等待和接收？就像第一个 rank 0 等待 rank 1 到 Recv，然后 rank 1 等待 rank 0 到 Recv？这样的交换配对安排是否更正确？

Answer 1

您的条件满足以下条件：

MPI_Isend 后跟 MPI_Wait 都完成了：

A.对应Isend中使用的缓冲区又可以使用了。

如果您要使用MPI_Issend 和MPI_Wait：

几乎 B.在相应的Recv发布时返回。

在MPI_Send之后，以下是正确的：

C.保证匹配 Recv 可以在接收进程返回后的某个稍后时间完成。

在您建议的非阻塞广播中，您必须允许交换 3. 和 4.，否则会出现死锁。这意味着，不能有一个严格的条件，即 4. 发生在 3 之后。由于 3 发生在根上，4 发生在所有其他等级上，所以它甚至可能不是问题。

不过，我建议改用更清洁的方法：

1. MPI_Isend 所有进程的根目录
2. MPI_Irecv 来自根目录的 **all88 个进程
3. 做一些其他工作（在所有进程上）
4. MPI_Waitall 用于所有级别的所有已发布请求（send/recv）

这应该是干净的实施和工作得很好。当然，这不是一个优化的集体……但那是另一个话题。