我已经阅读了所有 MPI 文档和教程以及我能找到的与此相关的 Stack Overflow 问题,但我仍然不完全理解 MPI_Wait 在“完成”MPI_Isend 时的行为方式。能简单概括一下吗?是吗
- A.对应Isend中使用的buffer可用时返回 再次(我想是的,但这并没有告诉我我想要的一切 知道)。
- B.当相应的Recv完成时返回(我认为不是 必然,但有时如果消息很大?)
- C.保证Recv在返回后的某个时间可以被接收进程完成
我问是因为我正在尝试实现一种非阻塞广播(因为 MPI_Ibcast 是 MPI 3 的东西,而且在我实际遇到的任何实现中似乎都不存在)。我目前在每个过程中遵循的顺序是这样的:
MPI_Isend
从每个进程到每个其他进程- 做一些其他的工作
MPI_Wait
让所有 Isends 都“完成”,无论这意味着什么MPI_Recv
所有消息
这在实践中似乎工作正常,但我不知道它是否保证工作,或者我只是幸运因为我的消息很小(它们每个只有一个 int,所以我怀疑它们会被 MPI 迅速洗牌到一些内部缓冲区或其他什么)。我不知道如果消息更大,这是否会造成死锁(我担心在这种情况下并非所有 MPI_Waits 都会返回,因为有些 MPI_Recvs 可能会死锁等待另一个进程发生)。
如果不能保证这在一般情况下有效,是否至少可以保证对非常小的消息有效?或者甚至这不一定是真的?我真的不确定我能指望什么。
如果这不能保证有效,那么如何实现非阻塞广播?也许有一些巧妙的执行 Waits 和 Recvs 的顺序?像第一个rank 0等待rank 1到Recv,然后rank 1等待rank 0到Recv?像这样的某种交换配对安排是否更正确?
最佳答案
满足以下条件:
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 发生在所有其他等级上,所以这甚至可能不是问题。
不过,我建议改用更简洁的方法:
MPI_Isend
在根上到所有进程MPI_Irecv
在 **all88 processes from root- 做一些其他工作(在所有流程上)
MPI_Waitall
所有级别上的所有已发布请求(send
/recv
)
这应该很容易实现并且工作得很好。当然,这不是一个优化的集体……但那是另一个话题。
关于c++ - MPI_Isend 之后 MPI_Wait 的确切行为是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57970356/