search

mpiwg-rma / rma-issues

Repository to discuss internal RMA working group issues
1 stars 0 forks source link

MPI_Win_get_group returning a duplicate of the group of comm? #18

Closed devreal closed 6 months ago

devreal commented 3 years ago

The description for MPI_WIN_GET_GROUP states that:

MPI_WIN_GET_GROUP returns in group a duplicate of the group of the communicator used to create the window associated with win.

Glancing over the code of Open MPI, the returned group is not a duplicate and there was some confusion over this language during the June 2021 Forum meeting. Was the intention to require a duplication of the group? How does MPICH implement this? Should this be fixed in 4.1?

hjelmn commented 3 years ago

Hmm, that seems like an error in the standard. MPI_Comm_group explicitly allows the implementation to return the group not just a copy. Perhaps the language should be the same for MPI_Win_get_group? Forcing the implementation to make a copy is incredibly inefficient.

jdinan commented 3 years ago

Groups are immutable and have no user-accessible metadata (e.g. attributes), so there should be no functional difference between a duplicate and a reference to the original group. I think we used this language in RMA just to reassure users that they can free the returned group without affecting the window.

~Jim.

On Mon, Jun 7, 2021 at 11:10 AM Joseph Schuchart @.***> wrote:

The description for MPI_WIN_GET_GROUP states that:

MPI_WIN_GET_GROUP returns in group a duplicate of the group of the communicator used to create the window associated with win.

Glancing over the code of Open MPI, the returned group is not a duplicate and there was some confusion over this language during the June 2021 Forum meeting. Was the intention to require a duplication of the group? How does MPICH implement this? Should this be fixed in 4.1?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mpiwg-rma/rma-issues/issues/18, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZ5P4XP5IGIH65TN2YGZOLTRTOOHANCNFSM46H4FFUA .

hjelmn commented 3 years ago

See §2.5 on page 19 of the latest RC. Maybe we should add MPI_WIN_GET_GROUP there? Seems like a good candidate for a ticket 0 change.

hjelmn commented 3 years ago

Or maybe copy the advice to implementors from page 315 to the one-sided chapter.

rsth commented 3 years ago

There is an MPI_File_get_group that uses the same language.

devreal commented 3 years ago

It does indeed make sense to call it a 'duplicate' since the user is responsible for freeing the resulting group again. Interestingly, this is less clear for MPI_Comm_group although it is implied in the context of the group description. Technically, all group constructors (incl. MPI_Comm_group, MPI_Win_get_group, ...) return a new group object that has to be free'd later. Ref-counting is merely an optimization.

devreal commented 6 months ago

This is a non-issue.