第七章MPI编程2.ppt

消息缓冲引起的发送次序和接收次序的关系问题 一对sender/receiver之间，如果receiver中的一个MPI_Recv能够与sender发送的多条消息都匹配，实际接收的是哪条消息？ ANY_SOURCE引起的发送次序和接收次序的关系问题 一个receiver与多个sender之间，如果每个sender所发送的消息都能receiver所执行的MPI_Recv匹配，实际接收的是哪个sender发送的消息？ 问题 * * 例如 在一对sender/receiver之间，希望按顺序依次msg1和msg2从sender传递给receiver sender的进度比receiver快，在sender执行完了这两条消息的MPI_Send之后，receiver才执行到第一个MPI_Recv MPI_Recv使用MPI_ANY_TAG为消息标签 msg1和msg2都被MPI缓存在系统缓冲区中 MPI_Recv所接收的消息是msg1还是msg2 ？编程者预期的是接收msg1 * * * * MPI的消息传递语义—Order 当消息发送者sender向消息接收者receiver所发送的连续多条消息能够与同一个MPI_Recv匹配，如果第一条消息pending状态，那么该MPI_Recv一定不会接收其它的消息 当消息的接收者receiver向MPI提交(post)的连续多个MPI_Recv都能与同一个消息匹配，如果第一个MPI_ Recv的请求还处于pending状态，那么该消息不会被MPI用来满足其它MPI_Recv的消息接收请求 对于MPI_Send/MPI_Recv这种阻塞通信，任何时刻，每个receiver最多只有一个消息接收请求处于 posted状态 但MPI提供了允许一个进程的多个消息传递请求同时处于posted状态的机制(非阻塞通信) * * 对于MPI_Send/MPI_Recv，可以理解为MPI在每对sender和receiver之间实现了一组FIFO(First In First Out)通道隧道(tag)，每个消息标签tag有一个唯一的通道 MPI_Send：向对应通道的push操作，把消息放到通道的末尾 MPI_Recv 检查哪些满足要求(符合消息的tag和source)的通道，进行消息匹配 从中选择一个匹配成功的通道，对该通道执行pull操作，从中取出匹配成功的第一条消息 * * 考虑下面代码中，0号进程接收从哪个进程接收消息 tag=10; If (my_rank==0) MPI_Recv(buf, count, MPI_INT, MPI_ANY_SOURCE, tag, MPI_COMM_WORLD, status); else MPI_Send(buf, count, MPI_INT, 0, tag, MPI_COMM_WORLD); 0号进程的MPI_Recv可以与其他任何进程的MPI_Send匹配 * * MPI的order语义表明， 0号进程的MPI_Recv可能消费其他任何进程所发送来的消息。因此，上述代码完成之后，0号进程的buf中的内容是不确定的，取决于MPI系统的实现。 因此，在使用MPI_ANY_SOURCE时，为了保证应用程序计算结果的确定性，需要应用程序根据消息接收语句完成后的status确定发送方sender 确定性：应用程序每次执行时，只要计算数据相同，计算的结果也相同 * * ANY_SOURCE引起的公平性(fairness)问题 MPI的order语义表明，一个send请求被posted之后，即使消息的接收方不断地post与该send相匹配的receive请求，该send请求的消息可能永远也不会被接收。 * * 示例 tag=10; flag=true; If (my_rank==0) while(flag) { MPI_Recv(buf, count, MPI_INT, MPI_ANY_SOURCE, tag, MPI_COMM_WORLD, status); consumer(buf); } else while(flag){ producer(buf); MPI_Send(buf, count, MPI_INT, 0, tag, MPI_COMM_WORLD); } 一种可能的情形是：0号进程每次总是从2号进程接收数据进行处理，其它进程虽然也产生了很多数据，但始终没有被0号进程接收 * * MPI的消息传递语义—fairness MPI不保证消息处理的公平性 发送者提交了(post)一条消息msg; msg的意中接收者receiver不断提交(post)能够与msg匹配的消息接收请求 实际中可能发生msg一直都没有被receiver接收的情况 * * MPI消息传递的f