[Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL, MPI_ADDRESS_NULL)

Fri Oct 22 08:25:52 CDT 2021

No I certainly do not hope so,

I would suggest that only an MPI implementation with a "pedantic" mode
would check for this. For any production level implementation the check for
MPI_PROC_NULL (if present in the implementation) will be sufficient. If
MPI_TAG_NULL is provided with a valid processor argument (against the
suggested standard wording) the probe code will run through all pending
messages and not find any matching tag since MPI_TAG_NULL is not inside the
0..MPI_TAG_UB range. Just as a probe for MPI_PROC_NULL today could
(should?) be scanning all messages.

Probes with either MPI_PROC_NULL or MPI_TAG_NONE should not need fast
lanes. Let them suffer by checking every message and find that there is
nothing for them. Then, if you are nice, you can raise an error before
returning.

If tags are implemented as signed integers MPI_TAG_NULL would most likely
be implemented as a negative value (which by the standard is not in the
valid tag range). If tags are implemented using unsigned int values, the
implementation could set MPI_TAG_NULL to "huge(unsigned 0)" and MPI_TAB_UB
to MPI_TAG_NULL-1. Either way it should not break existing implementations
(famous last words, I know...).

On Fri, Oct 22, 2021 at 3:02 PM Rolf Rabenseifner <rabenseifner at hlrs.de>
wrote:

> Do I understand correctly, that this proposal must add an additional
> lateny (internal if statement) to MPI_PROBE for *all* messages
> and also in most implementations (that do not want to ignore the
> error-checking
> when MPI_TAG_NULL is passed) for *all* point-to-point messages,
> but
> it this new MPI_TAG_NULL feature may be rearely used and extremly rarely
> used
> in MPI_PROBE?
>
> ----- Original Message -----
> > From: "Comments on the MPI Standard" <mpi-comments at lists.mpi-forum.org>
> > To: "Comments on the MPI Standard" <mpi-comments at lists.mpi-forum.org>
> > Cc: "Nils Smeds" <nils.smeds at gmail.com>
> > Sent: Friday, October 22, 2021 2:33:36 PM
> > Subject: Re: [Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and
> MPI_TAG_NULL, MPI_ADDRESS_NULL)
>
> > Dan,
> >
> > Thank you for your encouraging response.
> >
> > Firstly, let me state that I have no strong feelings for either
> MPI_ADDRESS_NULL
> > nor MPI_COMM_NULL other than they would satisfy my sense of "symmetry" or
> > "closure". In my own programming I rarely find myself unclear what buffer
> > address or communicator a specific code section is targeting. Most often
> it is
> > the pt2pt matching triad (proc,tag,comm) that needs to be tailored to
> express
> > the "intent" of the code so that an unimplemented fringe case does not
> pass by
> > unnoticed. (Merely causes a dead-lock - as if that is any help - I
> know...)
> >
> > My view of the MPI_*_NULL entities in the standard is that they are
> comparable
> > to NaN in floating point. MPI_TAG_NULL is not a member of the set of
> valid
> > tags, and can not be matched in any tag comparison operation, not even
> itself
> > or as "not a member of". MPI_TAG_ANY should not match a message with
> > MPI_TAG_NULL, and there should indeed be no way to create a "real"
> message with
> > MPI_TAG_NULL. So a statement as you suggested
> >
> >
> >
> > " W hen the tag argument is MPI_TAG_NULL the only allowed processor
> argument is
> > MPI_PROC_NULL"
> >
> > preferably in section 3.2.4 just before the last sentence describing the
> use of
> > dest=MPI_PROC_NULL would be all that is needed. A probe for such a
> message
> > (that can never be created as a "real" message) will thus return a status
> > object with a count of 0 and a tag of MPI_TAG_ANY and no change in
> behaviour to
> > existing implementations.
> >
> > So the updated suggested changes to the standards are:
> >
> >    1.
> > Insert into appendix "A1 Assorted constants": MPI_TAG_NULL
> >
> >    2.
> > Insert into section "9.1.2 Environmental Inquiries"
> >
> >
> >
> > (Line 34, end of first paragraph) [... is also a valid value for
> MPITAG_UB]. The
> > constant MPI_TAG_NULL shall have a value outside of the 0...MPI_TAG_UB
> range.
> >
> >    3.
> > Insert into section 3.2.4 before the last sentence (line 42.5):
> >
> > " W hen the tag argument is MPI_TAG_NULL the only allowed processor
> argument is
> > MPI_PROC_NULL"
> >
> >    4.
> > Add to section 3.10 "Null processes", last in the section:
> >
> > " Advice to users: Note that MPI_TAG_NULL is not a valid tag in the
> > 0..MPI_TAG_UB range. Thus MPI_TAG_NULL is only allowed when the
> associated
> > processor argument is MPI_PROC_NULL"
> >
> > To avoid a lengthy discussion into what probes of non-existing messages
> should
> > return as a result, I suggest that the committee sees any triad
> (proc,tag,comm)
> > where either component has a "NULL" value as defined in the standard
> (currently
> > only MPI_PROC_NULL exists) is in essence a "NaN"-triad, and returns the
> already
> > defined result of 0 elements of (MPI_PROC_NULL,MPI_ANY_TAG) as of
> section 3.10.
> > Also, just by chance, this would not conflict with an introduction of an
> > MPI_COMM_NULL item in the future.
> >
> >
> >
> > 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.
> >
> > Would MPI_TAG_NULL be valid for a point-to-point send operation that
> does NOT
> > use MPI_PROC_NULL but is matched with receive operation at the
> destination MPI
> > process that uses MPI_ANY_TAG? Or should this be an
> MPI_ERR_ARG/MPI_ERR_TAG
> > error condition? Commonly, codes that use MPI_ANY_TAG in receive
> operations
> > must choose an arbitrary valid tag value to use in the send operations
> at the
> > source MPI process(es). Permitting the use of MPI_TAG_NULL in
> combination with
> > MPI_ANY_TAG might aid debugging when the matching does not go the way
> the user
> > expected. However, it would add complexity to the matching
> > rules/implementation. There is an interaction here with INFO key
> assertions
> > such as `mpi_assert_no_any_tag` — which means the error could be
> discovered at
> > the sender process -- and `mpi_assert_only_any_tag` (if that one ever
> gets
> > accepted into MPI).
> >
> > There is already an MPI constant that is commonly set to `(void*)0` (in
> C),
> > which is MPI_BOTTOM. Defining MPI_ADDRESS_NULL to be the same value is
> not a
> > good idea because MPI_BOTTOM is a valid address; although attempting to
> > read/write at that address is likely to cause trouble, using it as a
> base for a
> > user-defined datatype or a window offset is common/accepted practice.
> Would it
> > be sufficient for your purposes to use MPI_BOTTOM as your “not valid”
> value?
> >
> > 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>”
> >
> > Cheers,
> > Dan.
> > —
> > Dr Daniel Holmes PhD
> > Executive Director
> > Chief Technology Officer
> > CHI Ltd
> > [ mailto:danholmes at chi.scot | danholmes at chi.scot ]
> >
> >
> >
> >
> >
> >
> > On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments < [
> > mailto:mpi-comments at lists.mpi-forum.org |
> mpi-comments at lists.mpi-forum.org ] >
> > wrote:
> >
> > Summary:
> > - Suggestion to introduce MPI_TAG_NULL in the standard with an obviously
> illegal
> > value (i.e. <0)
> > - Explicitly allow Point-to-Point messages to have one of more of: tag
> > MPI_TAG_NULL, datatype MPI_DATATYPE_NULL, invalid buffer addresses
> (including
> > MPI_ADDRESS_NULL) and communicator MPI_COMM_NULL, if (and only if) the
> > corresponding send or receive argument is MPI_PROC_NULL.
> >
> > Argument:
> > When writing code it is useful if it goes off with a bang when you do
> something
> > wrong. To catch matching errors in sends and receives I looked for a
> > MPI_TAG_NULL to use as a default value to catch cases where the tag was
> not set
> > correctly. I found that there was no such item. Referring to the
> standard I
> > found that tag values are restricted to the values 0...MPI_TAG_UB, where
> > MPI_TAG_UB (>=32767) can be found using the MPI_Comm_get_attr() function.
> >
> > So I used my own value for MPI_TAG_NULL as -1 and coded away. However,
> the MPI
> > implementation I was using blew up when I used it in a MPI_Sendrecv with
> the
> > remote task being MPI_PROC_NULL throwing an error message "illegal tag
> value",
> > which was no surprise to me since I had set it to this value explicitly.
> >
> > The workaround is of course to put a if( PartnerTask != MPI_PROC_NULL )
> { ... }
> > around every point-to-point call, but I find it unnecessary and makes
> the code
> > look more complex. I think that MPI_PROC_NULL was invented for exactly
> this
> > purpose, to be a transparent if(...) clause for the operation. Is there
> really
> > a need to be restrictive on datat ype, tag or any other argument when
> the P2P
> > operation is with MPI_PROC_NULL?
> >
> > I would expect implementations to choose MPI_ADDRESS_NULL be equal to
> (*) 0 in C
> > and 0_MPI_ADDRESS_KIND in Fortran and MPI_TAG_NULL to be default integer
> kind
> > -1.
> >
> > Implementation:
> > Append to section "3.10 Null processes" text along the lines of:
> >
> >
> >
> > A call to any point-to-point messaging function with a process argument
> of
> > MPI_PROC_NULL is allowed to have any value for buffer address, data
> type, tag
> > and communicator including MPI_ADDRESS_NULL, MPI_DATATYPE_NULL,
> MPI_TAG_NULL
> > and MPI_COMM_NULL without causing an error condition in the execution.
> >
> > Insert into appendix "A1 Assorted constants"
> >
> >
> >
> > MPI_TAG_NULL and MPI_ADDRESS_NULL
> >
> > Insert into section "9.1.2 Environmental Inquiries" (which is an odd
> place where
> > Tag values are specified in the standard):
> >
> >
> >
> > (Line 34, end of first paragraph) [... is also a valid value for
> MPITAG_UB]. The
> > constant MPI_TAG_NULL shall have a value outside of the 0...MPI_TAG_UB
> range.
> > The value MPI_TAG_NULL is erroneous to use in any communication unless
> the
> > associated process argument is MPI_PROC_NULL.
> >
> > Add to section "15.3.3 Convention for Returning Strings"
> >
> >
> >
> > The constant MPI_ADDRESS_NULL can be used as an equivalent to the null
> pointer.
> >
> >
> >
> > /Nils Smeds
> >
> > _______________________________________________
> > mpi-comments mailing list
> > [ mailto:mpi-comments at lists.mpi-forum.org |
> mpi-comments at lists.mpi-forum.org ]
> > [ https://lists.mpi-forum.org/mailman/listinfo/mpi-comments |
> > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments ]
> >
> >
> > _______________________________________________
> > mpi-comments mailing list
> > mpi-comments at lists.mpi-forum.org
> > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments
>
> --
> 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) .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-comments/attachments/20211022/789d2674/attachment-0001.html>