考虑配置是在消息传递（MPI）MPI_SEND和recv “什么等待”
第一：
不进行缓冲，阻塞（同步）
据我所知MPI是一个API，所以当我们做mpi_send阻塞函数调用时，发送函数/程序是否被阻塞？
OR
是否MPI API函数mpi_send被阻塞，从而使直至发送邮件程序可以继续工作？
二：
类似的困惑，莫非mpi_recv被阻塞或从它被调用的函数被封锁？
之所以这么愚蠢的问题：
它的并行处理，为什么会有人做的东西会阻止谁想要的一些信息的过程？
另一个原因：
这可能是当mpi_send通过这个过程被称为，没有其他进程可以使用mpi_send功能，因为它的工作？
首先：是的，调用程序被“阻塞”，因为直到消息被“发送”，MPI_Send调用才会返回。
第二：MPI_Recv也是一个“阻塞”调用，并且直到消息被“接收”才会返回。
一些额外的信息：
MPI_SEND是一种“堵”的呼叫，因为直到该消息已发送的通话将无法控制返回给调用者。而“发送”的定义是保存消息的用户缓冲区可以安全地重用。不能保证已收到该消息，或者甚至在远程排名中已经达到了MPI_Recv呼叫。 （确切的行为是依赖于实现的RDMA样式互连导致大多数问题与“黑盒子内部”行为的确切问题有关。）
MPI_Isend是一个“非阻塞”调用。控制将立即返回到调用程序...但是在程序调用MPI_Test或MPI_Wait来确认消息已被“发送”之前，缓冲区不能被重用。
“阻塞”调用的目的是为调用程序提供一个肯定的确认，即持有该消息的缓冲区可以被重用（在MPI_Send的情况下）或可靠地读取和修改（在MPI_Recv的情况下） 。如果使用“非阻塞”（例如MPI_Isend，MPI_Irecv）调用，调用程序可以继续执行计算，但不能可靠地（或合法地）更改消息缓冲区，直到调用MPI_Wait或MPI_Test来完成消息事务。
对上一个问题的回答是否定的：某些进程可能被阻塞，等待发送或接收完成而其他进程正在执行。阻止呼叫仅在调用它们的进程中阻塞。