Overview of mpi4py Point-to-Point Communication

In the last article, we introduced the combined sending and receiving communication method in mpi4py. So far, we have made a brief introduction to various point-to-point communication methods provided in mpi4py, and given simple usage routines. Let's make a summary of point-to-point communication.

From the previous introduction, we can see that there are many modes of point-to-point communication, which can be divided into blocking communication, non-repetitive non-blocking communication and repeatable non-blocking communication, and each category can be divided into standard, buffered, ready and synchronous modes. To understand the behavior of various communication modes, the key is to understand how each mode uses the buffer. In short, the characteristics of using buffer in each mode can be summarized as follows: the standard transmission actually uses the default buffer provided by MPI environment; Buffered Bsend is actually equivalent to putting the buffer provided by MPI environment in user space management; Ready Rsend is actually equivalent to no buffer, but the sender can't wait in advance; Synchronizing Ssend is actually equivalent to not buffering, but allowing waiting. The working principle of each mode in asynchronous mode is similar, but it can be understood that another thread in MPI environment will do the actual message transmission in the background and communicate and synchronize with the main thread of MPI process through MPI_Wait*, MPI_Test* and other mechanisms.

Point-to-point communication needs special attention to prevent deadlock. There are many reasons for deadlock, and the most typical one is the deadlock caused by buffer contention, such as the following example:

The running results are as follows:

In the above example, two processes send and receive messages to each other at the same time, but because the messages sent and received are relatively small and do not exceed the default buffer capacity provided by MPI environment, they can be executed smoothly. Now, we try to change the count in the previous example to 1024 (or more, depending on your MPI environment configuration), and the running result is as follows:

Both processes are blocked when sending, because the sending operation of both processes starts before the receiving operation. When the amount of data sent exceeds the default buffer space provided by MPI environment, each process has to wait for the other party to start the receiving operation and directly take away the "redundant" data. However, because blocking sending is used, the sending functions of both parties will not return before receiving, so the receiving action cannot be executed, so both processes are blocked on the sending step because they are waiting for receiving, and the program is deadlocked.

For this type of deadlock, the solution is as follows:

We don't list these solutions one by one, just give an example, that is, adjust the execution order of statements to prevent deadlock, as follows:

The running results are as follows:

After the statement is adjusted, the sending operation of each process can be matched with the receiving operation of the other party first, and the next communication can be carried out after the message transmission is completed, so that the deadlock caused by buffer competition can be eliminated.

MPI has certain regulations on the execution order of message delivery, but MPI environment does not provide measures to ensure "fairness", as follows:

The above briefly summarizes the point-to-point communication in mpi4py. In the next article, we will introduce the basic concepts of group and communicator.