Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI users] mca_pml_ob1_send blocks
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-09-12 08:45:11


On Sep 8, 2009, at 1:06 PM, Shaun Jackman wrote:

> Hi Jeff,
>

My INBOX has been a disaster recently. Please ping me repeatedly if
you need quicker replies (sorry! :-( ).

(btw, should this really be on the devel list, not the user list?)

> I can see one sort of ugly scenario unfolding in my head. Consider two
> processes running the following pseudocode:
>
> req = MPI_Irecv
> while (!done) {
> while (MPI_Test(req)) {
> req = MPI_Irecv
> }
> MPI_Send(!me)
> MPI_Send(!me)
> }
>

Are the sends guaranteed to have matching receives elsewhere? If not,
this has potential to deadlock on the whole assuming-buffering issue...

If you're expecting the sends to be matched by the Irecv's, this looks
like an erroneous program to me (there will always be 2x as many sends
outstanding as receives).

> I'll describe one process here:
> * MPI_Test checks req->req_complete, which is false, then calls
> opal_progress (which finds two packets from the other guy).
> * Send two packets to the other guy.
>

...only if they're eager. The sends are *not* guaranteed to complete
until the matching receives occur.

> * MPI_Test checks req->req_complete, which is true, returns
> immediately. No progress is made.
> * MPI_Test checks req->req_complete, which is false, because no
> progress has been made since the last call. Call opal_progress (which
> finds two packets from the other guy).
> * Send two packets to the other guy.
>
> * MPI_Test checks req->req_complete, which is true, returns
> immediately. No progress is made.
> * MPI_Test checks req->req_complete, which is false, because no
> progress has been made since the last time. Call opal_progress (which
> finds two packets from the other guy).
> * Send two packets to the other guy.
>
> and loop.
>
> In each iteration through the loop, one packet is received and two
> packets are sent. Eventually this has to end badly.
>

Bad user behavior should be punished, yes. :-)

I'm not quite sure that I see the problem you're identifying -- from
what you describe, I think it's an erroneous program.

> Following is an untested fix to request_get_status.c. It checks
> req->req_complete and returns immediately if it is true. If not, it
> calls opal_progress() and checks req->req_complete again. If
> OMPI_ENABLE_PROGRESS_THREADS is defined, it only checks the once and
> does not call opal_progress(). It would look better if the body of the
> loop were factored out into its own function.
>

Hmm. Do you mean this to be in request_get_status.c or req_test.c?
(you mentioned MPI_TEST above, not MPI_REQUEST_GET_STATUS)

Is this the optimization I mentioned in my previous reply (i.e., if
req_complete is false, call opal_progress, and then check req_complete
again?) If so, I think it would be better to do it without an if loop
somehow (testing and branching, etc.).

> Cheers,
> Shaun
>
> int i;
> for (i = 0; i < 2; i++) {
> if( request->req_complete ) {
> *flag = true;
> /* If this is a generalized request, we
> *always* have to call
> the query function to get the status
> (MPI-2:8.2), even if
> the user passed STATUS_IGNORE. */
> if (OMPI_REQUEST_GEN == request->req_type) {
> ompi_grequest_invoke_query(request,
> &request->req_status);
> }
> if (MPI_STATUS_IGNORE != status) {
> *status = request->req_status;
> }
> return MPI_SUCCESS;
> }
> #if OMPI_ENABLE_PROGRESS_THREADS == 0
> if (i == 0)
> opal_progress();
> #else
> break;
> #endif
> }
> *flag = false;
> return MPI_SUCCESS;
>
>

-- 
Jeff Squyres
jsquyres_at_[hidden]