Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] [patch] Invalid MPI_Status for null or inactive request
From: Kawashima, Takahiro (t-kawashima_at_[hidden])
Date: 2012-10-15 21:49:50


George,

Thanks for your reply.

Yes, as you explained, a case specifying an inactive request for MPI_Test
is OK. But the problem is a case specifying an inactive request for
MPI_Wait, MPI_Waitall, and MPI_Testall, as I explained in my first mail.

See code below:

        /* make a inactive request */
        MPI_Recv_init(&buf, 1, MPI_INT, 1, 0, MPI_COMM_WORLD, &request);
        MPI_Start(&request);
        do {
            MPI_Test(&request, &completed, &status);
        } while (completed == 0);

        /* wait for an inactive request */
        MPI_Wait(&request, &status);

In this code, the ompi_request_t object is marked as inactive in
MPI_Test (ompi_request_default_test) but its req_status field remains
unchanged.

Succeeding MPI_Wait (ompi_request_default_wait) sets a user-supplied
status object using req_status field of the request in req_wait.c
line 57.

    if( MPI_STATUS_IGNORE != status ) {
        status->MPI_TAG = req->req_status.MPI_TAG;
        status->MPI_SOURCE = req->req_status.MPI_SOURCE;
        status->_ucount = req->req_status._ucount;
        status->_cancelled = req->req_status._cancelled;
    }

Thus, the user will see a non-empty status after MPI_Wait in the code
above.

You can see this phenomenon with my status.c attached in my first mail.
Run with -n 2.

To avoid this problem, we have two options.
 A. Set req_status field to empty when we mark a request
    as inactive, or
 B. Add if-statements for an inactive request in order to set
    a user-supplied status object to empty in ompi_request_default_wait
    etc.

For least astonishment, I think A. is better.

Regards,
Takahiro Kawashima,
MPI development team,
Fujitsu

> Takahiro,
>
> I fail to see the cases your patch addresses. I recognize I did not have the time to look over all the instances where we deal with persistent inactive requests, but at the first occurrence, the one in req_test.c line 68, the case you exhibit there is already covered by the test "request->req_state == OMPI_REQUEST_INACTIVE". I see similar checks in all the other test/wait files. Basically, it doesn't matter that we leave the last returned error code on an inactive request, as we always return MPI_STATUS_EMPTY in the status for such requests.
>
> Thanks,
> george.
>
>
> On Oct 15, 2012, at 07:02 , "Kawashima, Takahiro" <t-kawashima_at_[hidden]> wrote:
>
> > Hi Open MPI developers,
> >
> > How is my updated patch?
> > If there is an another concern, I'll try to update it.
> >
> >>>>> The bugs are:
> >>>>>
> >>>>> (1) MPI_SOURCE of MPI_Status for a null request must be MPI_ANY_SOURCE.
> >>>>>
> >>>>> (2) MPI_Status for an inactive request must be an empty status.
> >>>>>
> >>>>> (3) Possible BUS errors on sparc64 processors.
> >>>>>
> >>>>> r23554 fixed possible BUS errors on sparc64 processors.
> >>>>> But the fix seems to be insufficient.
> >>>>>
> >>>>> We should use OMPI_STATUS_SET macro for all user-supplied
> >>>>> MPI_Status objects.
> >>>> Regarding #3, see also a trac 3218. I'm putting a fix back today. Sorry
> >>>> for the delay. One proposed solution was extending the use of the
> >>>> OMPI_STATUS_SET macros, but I think the consensus was to fix the problem
> >>>> in the Fortran layer. Indeed, the Fortran layer already routinely
> >>>> converts between Fortran and C statuses. The problem was that we started
> >>>> introducing optimizations to bypass the Fortran-to-C conversion and that
> >>>> optimization was employed too liberally (e..g, in situations that would
> >>>> introduce the alignment errors you're describing). My patch will clean
> >>>> that up. I'll try to put it back in the next few hours.
> >>>
> >>> Sorry, I didn't notice the ticket 3218.
> >>> Now I've confirmed your commit r27403.
> >>> Your modification is better for my issue (3).
> >>>
> >>> With r27403, my patch for issue (1) and (2) needs modification.
> >>> I'll re-send modified patch in a few hours.
> >>
> >> The updated patch is attached.
> >> This patch addresses bugs (1) and (2) in my previous mail
> >> and fixes some typos in comments.