Open devreal opened 8 months ago
We will hold a WG meeting week after the forum … are you want to read this in June ?Anthony Skjellum, PhD205-807-4968On Mar 14, 2024, at 12:05 PM, Joseph Schuchart @.***> wrote: Problem The text is not clear on whether partitioned communication operations have similar semantics as persistent communication operations. Chapter 4 mentions persistent communication mostly to distinguish partitioned and persistent communication. Given that partitioned operations are explicitly started one can infer that they are similar to persistent operations but it is not explicitly stated. Throughout the document we only mention persistent operations when their semantics differ from nonblocking operations (finalization, test/wait, Chapter 2) but don't explicitly mention partitioned operations there. The standard should clarify the relation between partitioned communication and persistent communication. Proposal Add wording that states that partitioned communication operations behave like persistent operations with the exception of how communication is enabled. Changes to the Text Proposal by @Wee-Free-Scot to add to Chapter 4:
Partitioned operations initialised with MPI_Psend_init or with MPI_Precv_init are persistent communication operations with the same semantics as all other persistent communication operations (see chapter 2) except for the addition of the semantics described for the MPI_Pready and MPI_Parrived procedures.
Alternative (less desirable): make partitioned operations a stand-alone entity that gets mentioned everywhere persistent operations are mentioned (outside of the definition of persistent operations). Impact on Implementations None. Impact on Users Clarity on what requirements exist for partitioned communication. References and Pull Requests TBD
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
It should be explicitly stated that partitioned point-to-point operations are persistent operations. This text is ideal from Dan @Wee-Free-Scot
Partitioned operations initialized with MPI_Psend_init or with MPI_Precv_init are persistent communication operations with the same semantics as all other persistent communication operations (see chapter 2) except for the addition of the semantics described for the MPI_Pready and MPI_Parrived procedures. [spelling of one word changed to US English for consistency with the rest of the document.]
Who wants to do the PR?
This begs the question of what persistent semantics would this refer to? There are other semantic differences between partitioned communication and persistent send/recv; such and when matching occurs, what operations can be matched against. It seems to me that the statement needs more room for nuance.
Problem
The text is not clear on whether partitioned communication operations have similar semantics as persistent communication operations. Chapter 4 mentions persistent communication mostly to distinguish partitioned and persistent communication. Given that partitioned operations are explicitly started one can infer that they are similar to persistent operations but it is not explicitly stated. Throughout the document we only mention persistent operations when their semantics differ from nonblocking operations (finalization, test/wait, Chapter 2) but don't explicitly mention partitioned operations there.
The standard should clarify the relation between partitioned communication and persistent communication.
Proposal
Add wording that states that partitioned communication operations behave like persistent operations with the exception of how communication is enabled.
Changes to the Text
Proposal by @Wee-Free-Scot to add to Chapter 4:
Alternative (less desirable): make partitioned operations a stand-alone entity that gets mentioned everywhere persistent operations are mentioned (outside of the definition of persistent operations).
Impact on Implementations
None.
Impact on Users
Clarity on what requirements exist for partitioned communication.
References and Pull Requests
TBD