MPI_PROC_NULL behavior for MPI_PROBE and MPI_IPROBE not directly defined

[mpiforumbot]

Originally by jsquyres on 2010-09-16 09:28:59 -0500

---

Discovered while reading the MPROBE proposal at the Stuttgart MPI Forum meeting:

MPI-2.2 does not seem to directly define what the behavior is if you specify MPI_PROC_NULL to MPI_PROBE or MPI_IPROBE. Indeed, MPI_PROC_NULL is not defined until ~10 pages later (MPI_IPROBE/PROBE is defined starting on page 64; MPI_PROC_NULL is defined on page 75).

Bill Gropp detected that it is defined indirectly.
MPI_IPROBE states in MPI-2.2, page 65, lines 30-32:

The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program, and returns in status the same value that would have been returned by MPI_RECV().

The MPROBE ticket #38 has a definition for what happens with MPI_PROC_NULL; it is likely that that same definition should also be applied to MPI_PROBE and MPI_IPROBE:

A matching probe with MPI_PROC_NULL as source returns flag # true, messageMPI_MESSAGE_NULL, and the status object returns source # MPI_PROC_NULL, tagMPI_ANY_TAG, and count = 0; see Section 3.11.

The following solution is therefore only a clarification
and getting the text consistent (text (only) changes).
It is not a correction or enhancement to the standard.

Proposed Solution

• '''Add the following paragraph at the end of the
  description of MPI_RECV, i.e. after the description of MPI_ANY_SOURCE, i.e., at
  MPI-2.2, Chapter 3 (Point-to-Point), page 31, after line 44:'''

  The use of dest or source=__MPI_PROC_NULL
  to define a "dummy" destination or source in any send or receive
  call is described in Section 3.11 on page 75.__

[[BR]]

• '''Add the following paragraph at the end of the
  description of MPI_IPROBE, i.e., at
  MPI-2.2, Chapter 3 (Point-to-Point), page 65, after line 47:'''

  A probe with __MPI_PROC_NULL as source returns
  flag = true, and the status object returns
  source # MPI_PROC_NULL, tagMPI_ANY_TAG,
  and count = 0; see Section 3.11 on page 75.__

[[BR]]

• The end of the description of MPI_PROC_NULL, MPI-2.2, page 75, line 48 - page 76, lines 3 reads

  A receive from MPI_PROC_NULL succeeds and returns as
  soon as possible with no modifications to the receive buffer.
  When a receive with source = MPI_PROC_NULL is executed
  then the status object returns source = MPI_PROC_NULL,
  tag # MPI_ANY_TAG and count0.

  -but should read*

  A receive from MPI_PROC_NULL succeeds and returns as
  soon as possible with no modifications to the receive buffer.
  When a receive with source = MPI_PROC_NULL is executed
  then the status object returns source = MPI_PROC_NULL,
  tag # MPI_ANY_TAG and count0.
  A probe or matching probe with source = __MPI_PROC_NULL
  succeeds and returns as soon as possible,
  and the status object returns source = MPI_PROC_NULL,
  tag # MPI_ANY_TAG and count0.__

Entry for the Change Log

Section 3.8 on page 64 and Section 3.11 on page 75.[[BR]]
The use of MPI_PROC_NULL in probe and matching probe
operations was clarified.

[mpiforumbot]

Originally by gropp on 2010-09-27 10:29:29 -0500

---

MPI_PROC_NULL is first mentioned on p26 line 16.

I view this as a clarification, as the language for probe says

The call matches the same message that would have been received by a call to 
MPI_RECV(..., source, tag, comm, status) executed at the same point in the program, and 
returns in status the same value that would have been returned by MPI_RECV(). Otherwise, 
the call returns flag = false, and leaves status undefined.

and since MPI_PROC_NULL is valid for a call to MPI_RECV, it should be valid for a call to MPI_PROBE and MPI_IPROBE. However, a specific clarification about the MPI_PROC_NULL case could be added (it need only point forward to the discussion - rather than add text that is supposed to duplicate what is given there).

[mpiforumbot]

Originally by RolfRabenseifner on 2012-01-17 05:49:05 -0600

---

I propose that at least Jeff, Torsten and Rich review this proposal.
For me, it is now okay, therefore schduled for reading in the next forum meeting.

[mpiforumbot]

Originally by jsquyres on 2012-02-01 19:20:46 -0600

---

I have re-reviewed this ticket and agree -- it should be read at the next Forum meeting.

[mpiforumbot]

Originally by goodell on 2012-03-06 16:16:16 -0600

---

Modified description to cover MPI_IMRECV, reset priority for re-reading tomorrow morning.

[mpiforumbot]

Originally by goodell on 2012-03-06 17:16:55 -0600

---

Undo the recent change after further discussion here at the meeting. A new ticket will be opened covering this case instead.

[mpiforumbot]

Originally by jsquyres on 2012-07-18 09:57:04 -0500

---

Appears to be fully committed. Moving to "Waiting for PDF reviews".