[Mpi-comments] Suggestion for MPI_COMM_NULL
Nils Smeds
nils.smeds at gmail.com
Fri Oct 22 08:30:29 CDT 2021
[This is a branch-off from thread "Pt2pt messaging with MPI_PROC_NULL (and
MPI_TAG_NULL,MPI_ADDRESS_NULL)" ]
It turns out that MPI_COMM_NULL opens some questions that I am sure can be
resolved by people on the list.
It is enlightening that you see my suggested MPI_COMM_NULL as a set and not
an item. I did not think about that, but it is of course the more natural
approach and MPI_COMM_NULL can then be seen as problematic. I do indeed
have the view that the MPI_xxxx_NULL items are to be compared to NaN in
that they are items in themselves. In particular they are items that are
not members of any set of similar items. Thus, MPI_COMM_NULL is a process
communicator that is not a member of any set of (valid) process
communicators and it is not MPI_COMM_EMPTY.
I am not sure that there is a need for an explicit MPI_COMM_EMPTY, but if
there was it is allowed and can be created as a sub-communicator to any
communicator by MPI_Comm_create, eg for MPI_COMM_WORLD:
MPI_Comm_create(MPI_COMM_WORLD,MPI_GROUP_EMPTY,&mpi_comm_empty)
but its usefulness I find debatable.
The set operations in MPI are, I believe, restricted to the MPI_GROUP_xxx
set of items and do not directly involve communicators, but I am on thin
ice here. This is for the intra-communicator people, MPMD and multi-physics
scientists to have opinions on. In my view, the group members of
MPI_COMM_NULL should be MPI_GROUP_NONE (not MPI_GROUP_EMPTY) if it should
return any members at all. My suggestion would rather be that MPI_COMM_NULL
is an illegal communicator argument in any call to MPI_Group_*() or
MPI_Comm_*() that takes a communicator as an argument, eg MPI_Comm_dup(),
MPI_Comm_free(), MPI_Comm_group().
So, I think that you and I are arguing for the same definition of
MPI_COMM_NULL .
/Nils
On Thu, Oct 21, 2021 at 7:14 PM Dan Holmes <danholmes at chi.scot> wrote:
> Hi Nils,
>
> In general, I like the idea of having default/invalid values for these
> MPI-related user variables.
> [...]
> IMHO, there would need to be a statement that, “when the comm argument is
> MPI_COMM_NULL, the only acceptable value for the source/dest argument is
> MPI_PROC_NULL” because asking for the 3rd item from an empty set (for
> example) is clearly an error. Your proposal tries to treat MPI_COMM_NULL as
> if it is a valid MPI intra-communicator that has size zero, or a valid
> inter-communicator that has a remote group of size zero. I think I would
> prefer to create MPI_COMM_EMPTY for that purpose, and continue to use
> MPI_COMM_NULL for situations that call for an invalid communicator, i.e.
> something that can never be used as a communicator without causing an error
> condition.
>
> The phrase used elsewhere in the MPI Standard is “XYZ parameter is
> significant only <when condition>”
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-comments/attachments/20211022/d80ab749/attachment.html>
More information about the mpi-comments
mailing list