[mpiwg-persistence] Completion call before all partitions marked ready

[Jim Dinan]

This came up recently and I believe it is allowed to wait/test a send
request before all partitions are marked as ready. It's not explicitly
stated, rather there is no restriction disallowing this usage. It may be
good to clarify this semantic (e.g. in Section 4.2.2) for MPI 4.1 since
this is a topic that the WG debated at length.

@Ryan Grant <ryan.grant at queensu.ca> Please fact check.

 ~Jim.

On Mon, Oct 10, 2022 at 7:22 AM Joachim Jenke via mpiwg-persistence <
mpiwg-persistence at lists.mpi-forum.org> wrote:

> Hello wg-persistence,
>
> Looking at the MPI 4.0 document, it is not clear to us, whether it is
> allowed to call a completion call for a partitioned communication
> request before all partitions are marked ready. A simple single-threaded
> example would be:
>
> ```C
> MPI_Psend_init(message, partitions, COUNT, MPI_DOUBLE, dest, tag,
>                 MPI_COMM_WORLD, MPI_INFO_NULL, &request);
> MPI_Start(&request);
> for(i = 0; i < partitions-1; ++i)
> {
>      MPI_Pready(i, request);
> }
> MPI_Test(&request, &flag, MPI_STATUS_IGNORE); // flag will always be 0
> MPI_Pready(partitions-1, request);
> MPI_Wait(&request, MPI_STATUS_IGNORE);
> MPI_Request_free(&request);
> ```
>
> The question becomes more relevant in a multi-threaded context. One
> thread could finish the work early and call MPI_Wait to detect when all
> partitions were sent.
>
>  From my understanding, the only requirement is that all partitions must
> be marked ready with explicit ready calls before the operation can
> complete. Replacing the test in above example with a wait call would
> result in deadlock.
>
> 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
> protze at itc.rwth-aachen.de
> www.itc.rwth-aachen.de
> _______________________________________________
> mpiwg-persistence mailing list
> mpiwg-persistence at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-persistence
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-persistence/attachments/20221012/fa581f4c/attachment.html>