[mpiwg-persistence] [mpiwg-semantic-terms] Summary of Semantics for Partitioned Communication Operations

Tue Jul 21 15:43:22 CDT 2020

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 at lists.mpi-forum.org>
> To: mpiwg-persistence at lists.mpi-forum.org
> Cc: "mpiwg-semantic-terms" <mpiwg-semantic-terms at 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 at lists.mpi-forum.org> on
> behalf of Bangalore, Purushotham via mpiwg-persistence
> <mpiwg-persistence at lists.mpi-forum.org>
> Sent: Wednesday, July 15, 2020 12:54 PM
> To: HOLMES Daniel <d.holmes at epcc.ed.ac.uk>
> Cc: mpiwg-semantic-terms at lists.mpi-forum.org
> <mpiwg-semantic-terms at lists.mpi-forum.org>;
> mpiwg-persistence at lists.mpi-forum.org <mpiwg-persistence at 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 at epcc.ed.ac.uk>
> Sent: Wednesday, July 15, 2020 12:42 PM
> To: Bangalore, Purushotham <puri at uab.edu>
> Cc: mpiwg-persistence at lists.mpi-forum.org
> <mpiwg-persistence at lists.mpi-forum.org>;
> mpiwg-semantic-terms at lists.mpi-forum.org
> <mpiwg-semantic-terms at 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 at epcc.ed.ac.uk | d.holmes at 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 at lists.mpi-forum.org |
> mpiwg-persistence at lists.mpi-forum.org ] > wrote:
> 
> <MPI-semantics-appendix.xlsx>
> 
> 
> --
> mpiwg-semantic-terms mailing list
> mpiwg-semantic-terms at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-semantic-terms

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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) .