Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use consistent wording "ready to be transferred" for partitions #833

Open
cniethammer opened this issue Feb 15, 2024 · 1 comment
Open
Assignees
Labels
chap-part Partitioned Communication Chapter Committee mpi-4.2 scheduled reading Reading is scheduled for the next meeting
Milestone

Comments

@cniethammer
Copy link

Problem

Some parts of the text in the partitioned chapter use the word 'inactive' for individual partitions. However, the term 'inactive' is (only) defined for operations in the terms chapter. Therefore, the phrase "ready to be transferred" should be used here instead.

Changes to the Text

https://github.com/mpi-forum/mpi-standard/pull/951

Impact on Implementations

Clarification for better understanding, no impact otherwise

Impact on Users

Clarification for better understanding, no impact otherwise

@cniethammer cniethammer added chap-part Partitioned Communication Chapter Committee mpi-4.2 labels Feb 15, 2024
@cniethammer cniethammer self-assigned this Feb 15, 2024
@Wee-Free-Scot
Copy link

Wee-Free-Scot commented Mar 4, 2024

MPI-4.1 section 2.4.1 page 11 line 39:
"Starting hands over control of the data buffers, if any, to the associated operation."
MPI-4.1 section 2.4.1 page 12 line 42:
"These four stages lead to the operation states initialized, started, complete, and"
MPI-4.1 section 2.4.1 page 12 line 43:
"A started operation is also named active,"
MPI-4.1 section 2.4.1 page 14 lines 45-47:
"Starting procedure: An MPI procedure is a starting procedure if return from the
procedure indicates that the associated operation has completed its starting stage,
which implies that the user has handed over control of the data buffers to MPI."

For partitioned send operations,

  • MPI is made aware of the location of the data buffer by the initialization procedure, MPI_Psend_init
  • The user is permitted to modify the contents of any partition of the data buffer until that partition is the object of a call to MPI_Pready
  • The call to MPI_Start/MPI_Startall for the partitioned operation does not change this permission-to-modify-content
  • De facto, the MPI_Pready procedure is a starting procedure because it hands over control of the content of the partition of the data buffer to MPI -- that partition is therefore started, which is a synonym of active
  • This non-action of MPI_Start/MPI_Startall is different to its normal action and should be called out to the readers: normally MPI_Start/MPI_Startall are starting procedures, but for partitioned operations they are semantic no-op procedures (except that it is not permitted to call MPI_Pready beforehand)

The original text for line 290 in the diff calls out the unusual non-action of MPI_Start/MPI_Startall with "not active" [good], the replacement elides this important detail [bad].

The original text for line 291 in the diff accurately describes the semantic action of MPI_Pready using the terms defined in the Terms chapter [good], the replacement elides this important terminology [bad] and introduces a new phrase which is not defined in the Terms chapter [ugly].

Line 292 of the diff is changed only for consistency with the previous changes; if they are stuck out from the PR, then the changes on this line must also be struck out.

IMHO, this issue should be withdrawn.

@wesbland wesbland added the scheduled reading Reading is scheduled for the next meeting label Mar 4, 2024
@wesbland wesbland added this to the March 2024 milestone Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chap-part Partitioned Communication Chapter Committee mpi-4.2 scheduled reading Reading is scheduled for the next meeting
Projects
Status: To Do
Development

No branches or pull requests

3 participants