Hi Joachim,
A naive implementation can simply wait for the entire message buffer to be marked ready before any transfer(s) occur and could wait until the completion function is called on a request before transferring data.
IMHO, the request mentioned here is intended to be the receive request, not the send request. That should be clarified to avoid the misunderstanding you highlight. While Process 0 is blocked in Recv(1), it must guarantee progress (which includes progress for all enabled operations, which includes the partitioned send operation). While Process 1 is blocked in Wait(r), it must guarantee progress (which includes progress for all enabled operations, which includes the partitioned receive operation). Thus, Process 1 must return eventually and will reach Send(0), which guarantees that Process 0 will also finish eventually. Best wishes, Dan. -----Original Message----- From: mpiwg-persistence <[email protected]> On Behalf Of Joachim Jenke via mpiwg-persistence Sent: 11 January 2023 14:05 To: [email protected] Subject: [mpiwg-persistence] progress rule vs. partitioned communication Hi all, while working on deadlock detection for partitioned P2P communication we could not really come to a conclusion, whether a variant of the following non-deadlock scenario is a deadlock with partitioned communication: Process 0 Process 1 MPI_Isend(1,r) MPI_Recv(0) MPI_Recv(1) MPI_Send(0) MPI_Wait(r) Transformed into partitioned communication: Process 0 Process 1 MPI_Psend_init(1,r) MPI_Precv_init(0,r) MPI_Start(r) MPI_Start(r) MPI_Pready_range(all,r) MPI_Wait(r) MPI_Recv(1) MPI_Send(0) MPI_Wait(r) The first example should not deadlock according to the process paragraph in MPI4,p75,l13pp:
A call to MPI_WAIT that completes a receive will eventually terminate > and return if a matching send has been started , unless the send is > satisfied by another receive. In particular, if the matching send is > nonblocking, then the receive should complete even if no call is > executed by the sender to complete the send.
The second example might potentially deadlock according to the rational in MPI4,p106,l3pp:
A naive implementation can simply wait for the entire message buffer > to be marked ready before any transfer(s) occur and could wait until > the completion function is called on a request before transferring > data.
If calling the completion function is necessary to eventually send the data, the second example will deadlock with Process 0 stalling in the MPI_Recv and Process 1 stalling in the MPI_Wait. From my perspective this contradicts the process definition for MPI_WAIT completing a receive where the matching send has been started. Another question might be when a partitioned send is started in the sense of the process rule for MPI_WAIT. I checked the current mpi-4.x branch and the referenced wording seems to be still the same. Did we miss something? Best Joachim -- Dr. rer. nat. Joachim Jenke IT Center Group: High Performance Computing Division: Computational Science and Engineering RWTH Aachen University Seffenter Weg 23 D 52074 Aachen (Germany) Tel: +49 241 80- 24765 Fax: +49 241 80-624765 [email protected] www.itc.rwth-aachen.de