Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] MPI_Mprobe
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-07-31 08:15:22


On Jul 31, 2012, at 2:58 AM, Eugene Loh wrote:

> The main issue is this. If I go to ompi/mpi/fortran/mpif-h, I see six files (*recv_f and *probe_f) that take status arguments. Normally, we do some conversion between Fortran and C status arguments. These files test if OMPI_SIZEOF_FORTRAN_INTEGER==SIZEOF_INT, however, and bypass the conversion if the two types of integers are the same size. The problem with this is that while the structures may be the same size, the C status has a size_t in it. So, while the Fortran INTEGER array can start on any 4-byte alignment, the C status can end up with a 64-bit pointer on a 4-byte alignment. That's not pleasant in general and can incur some serious hand-slapping on SPARC. Specifically, SPARC/-m64 errors out on *probe and *recv with MPI_PROC_NULL sources. Would it be all right if I removed these "shorts cuts"?

Ew. Yes. You're right.

What specifically do you propose? I don't remember offhand if the status conversion macros are the same as the regular int/INTEGER conversion macros -- we want to keep the no-op behavior for the regular int/INTEGER conversion macros and only handle the conversion of MPI_Status separately, I think. Specifically: for MPI_Status, we can probably still have those shortcuts for the int/INTEGERs, but treat the copying to the size_t separately.

Thanks for fixing the ibm MPROBE tests, btw. Further proof that I must have been clinically insane when I added all those tests. :-(

Related issue: do we need to (conditionally) add padding for the size_t in the Fortran array?

> Here are two more smaller issues. I'm pretty sure about them and can make the appropriate changes, but if someone wants to give feedback...
>
> 1) If I look at, say, the v1.7 MPI_Mprobe man page, it says:
>
> A matching probe with MPI_PROC_NULL as source returns
> message = MPI_MESSAGE_NULL...
>
> In contrast, if I look at ibm/pt2pt/mprobe_mpifh.f90, it's checking the message to be MPI_MESSAGE_NO_PROC. Further, if I look at the source code, mprobe.c seems to set the message to "no proc". So, I take it the man page is wrong? It should say "message = MPI_MESSAGE_NO_PROC"?

Oh, yes -- I think the man page is wrong. The issue here is that the original MPI-3 proposal said to return MESSAGE_NULL, but this turns out to be ambiguous. So we amended the original MPI-3 proposal with the new constant MPI_MESSAGE_NO_PROC. So I think we fixed the implementation, but accidentally left the man page saying MESSAGE_NULL.

If you care, here's the specifics:

https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/38
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/328

> 2) Next, looking further at mprobe.c, it looks like this:
>
> int MPI_Mprobe(int source, int tag, MPI_Comm comm,
> MPI_Message *message, MPI_Status *status)
> {
> if (MPI_PROC_NULL == source) {
> if (MPI_STATUS_IGNORE != status) {
> *status = ompi_request_empty.req_status;
> *message = &ompi_message_no_proc.message;
> }
> return MPI_SUCCESS;
> }
> ......
> }
>
> This means that if source==MPI_PROC_NULL and status==MPI_STATUS_IGNORE, the message does not get set. The assignment to *message should be moved outside the status check, right?

Agreed. Good catch.

Do the IBM MPROBE tests check for this condition? If not, we should probably extend them to do so.

-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/