Dear puri and all,

I expect that the proposed footnote

"20) Unlike MPI_SEND_INIT and MPI_RECV_INIT, MPI_PSEND_INIT and MPI_PRECV_INIT may communicate."

is incorrect.

MPI_SEND_INIT and MPI_RECV_INIT, MPI_PSEND_INIT and MPI_PRECV_INIT are all local
procedures and we know, that local is weak local and no line in the MPI
Standard can prohibit that a (weak) local is performing some "internal"
communication for optimization.
As long as the user's (= application programmer's) viewpoint can see
only a local routine, and the freeing is also a local routine,
even in the case that there was never an MPI_START, then all is fine.

Maybe you meant:
20) Although these are local routines, an MPI implementation may internally
already start some communication of metadata, but must guarantee that the INIT and the
MPI_REQUEST_FREE are both local procedures.

But such a comment should be an advice to implementors in the
definition of the MPI_P..._INIT routines, and not as a footnote here.

My comment is completely independent of what is written in the MPI Standard elsewhere.

MPI-3.1 p 73 line 41 on persistent pt-to-pt init:
"These calls involve no communication."

In principle, this sentence should be substituted by
"These procedures are local and do not send or receive any buffer content."

But this may be a cleanup for MPI 4.1 ;-)

Such a sentence should be part of the new partitioned comm. chapter!

Best regards
Rolf
                                        



----- Original Message -----
> From: "mpiwg-semantic-terms" <mpiwg-semantic-terms@lists.mpi-forum.org>
> To: mpiwg-persistence@lists.mpi-forum.org
> Cc: "mpiwg-semantic-terms" <mpiwg-semantic-terms@lists.mpi-forum.org>
> Sent: Tuesday, July 21, 2020 8:34:09 PM
> Subject: Re: [mpiwg-semantic-terms] [mpiwg-persistence] Summary of Semantics for Partitioned Communication Operations

> Here is the updated spreadsheet based on Dan's suggestions. I would really like
> the persistence WG to finalize this ASAP.
>
> I know Ryan would like to review the changes to the chapter before it is merged
> during tomorrow's meeting. If there is time left after that, I would like to
> discuss this.
>
> Thanks,
> Puri
>
>
> From: mpiwg-persistence <mpiwg-persistence-bounces@lists.mpi-forum.org> on
> behalf of Bangalore, Purushotham via mpiwg-persistence
> <mpiwg-persistence@lists.mpi-forum.org>
> Sent: Wednesday, July 15, 2020 12:54 PM
> To: HOLMES Daniel <d.holmes@epcc.ed.ac.uk>
> Cc: mpiwg-semantic-terms@lists.mpi-forum.org
> <mpiwg-semantic-terms@lists.mpi-forum.org>;
> mpiwg-persistence@lists.mpi-forum.org <mpiwg-persistence@lists.mpi-forum.org>
> Subject: Re: [mpiwg-persistence] Summary of Semantics for Partitioned
> Communication Operations
> Here are the other footnotes (I should have pasted them near footnote 20):
>
> 7) Addresses are cached on the request handle.
>
> 9) One shall not free or deallocate the bu er before the operation is freed,
> that is MPI_REQUEST_FREE returned.
>
> 14) Nonblocking procedure without an I pre fix.
>
> =====
> I will move PREADY,...,PARRIVED after START... good suggestion.
>
> I also agree with "ic" for the PREADY, PARRIVED procedures.
>
>
> From: HOLMES Daniel <d.holmes@epcc.ed.ac.uk>
> Sent: Wednesday, July 15, 2020 12:42 PM
> To: Bangalore, Purushotham <puri@uab.edu>
> Cc: mpiwg-persistence@lists.mpi-forum.org
> <mpiwg-persistence@lists.mpi-forum.org>;
> mpiwg-semantic-terms@lists.mpi-forum.org
> <mpiwg-semantic-terms@lists.mpi-forum.org>
> Subject: Re: [mpiwg-persistence] Summary of Semantics for Partitioned
> Communication Operations
> Hi Puri,
>
> Thanks for this - a great way to provoke some progress (no pun intended).
>
> I would suggest: move the rows dealing with MPI_PREADY and MPI_PARRIVED between
> MPI_START and MPI_WAIT, i.e. in the approximate calling order.
>
> Also, I would add “ic” for the new MPI_PREADY, MPI_PARRIVED, etc procedures -
> because the operation is definitely incomplete at the point in time they are
> called, during the time interval of their entire execution, and at the point in
> time they return - there is no possibility they could be completing or freeing
> procedures.
>
> What are the other footnotes: 7, 9, and 14? (I could look them up but I’d have
> to choose the same draft version as you because the numbering changed
> recently.)
>
> Cheers,
> Dan.
> —
> Dr Daniel Holmes PhD
> Architect (HPC Research)
> [ mailto:d.holmes@epcc.ed.ac.uk | d.holmes@epcc.ed.ac.uk ]
> Phone: +44 (0) 131 651 3465
> Mobile: +44 (0) 7940 524 088
> Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT
> —
> The University of Edinburgh is a charitable body, registered in Scotland, with
> registration number SC005336.
> —
>
>
>
>
> On 15 Jul 2020, at 18:24, Bangalore, Purushotham via mpiwg-persistence < [
> mailto:mpiwg-persistence@lists.mpi-forum.org |
> mpiwg-persistence@lists.mpi-forum.org ] > wrote:
>
> <MPI-semantics-appendix.xlsx>
>
>
> --
> mpiwg-semantic-terms mailing list
> mpiwg-semantic-terms@lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-semantic-terms

--
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de .
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 .
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 .
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner .
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .