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

Fri Oct 22 08:02:19 CDT 2021

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) .