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

[Dan Holmes]

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
danholmes at chi.scot



> On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments <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
> mpi-comments at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-comments

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-comments/attachments/20211021/8f4d3aca/attachment.html>