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

Question

我已经阅读了所有 MPI 文档和教程以及我能找到的与此相关的 Stack Overflow 问题，但我仍然不完全理解 MPI_Wait 在“完成”MPI_Isend 时的行为方式。能简单概括一下吗？是吗

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

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

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

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

如果不能保证这在一般情况下有效，是否至少可以保证对非常小的消息有效？或者甚至这不一定是真的？我真的不确定我能指望什么。

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

Answer 1

满足以下条件:

MPI_Isend 后跟 MPI_Wait 都完成了:

A. The buffer used in the corresponding Isend is usable again.

如果您要使用 MPI_Issend 和 MPI_Wait:

almost B. Return when the corresponding Recv is posted.

紧接在 MPI_Send 之后，以下内容为真:

C. Guarantee that a matching Recv can be completed by the receiving process at some later time after it returns.

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

不过，我建议改用更简洁的方法:

1. MPI_Isend 在根上到所有进程
2. MPI_Irecv 在 **all88 processes from root
3. 做一些其他工作(在所有流程上)
4. MPI_Waitall 所有级别上的所有已发布请求(send/recv)

这应该很容易实现并且工作得很好。当然，这不是一个优化的集体……但那是另一个话题。