Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-01-11 15:38:00


Ya -- see my later post -- I stood corrected. :-)

I already applied the patch to the 1.1 branch.

Thanks for the PML explanation.

On Jan 11, 2007, at 3:28 PM, George Bosilca wrote:

> Don't worry, I know what I'm doing. Moreover, the correct behavior is
> implemented in the f77 version of MPI_Start, but not in the f77
> version of MPI_Startall.
>
> On Jan 11, 2007, at 3:13 PM, Jeff Squyres wrote:
>
>> George --
>>
>> Why would the request ID numbers change after the invocation to the
>> back-end MPI_Startall()? The request ID numbers were allocated when
>> the requests were created, so there's no reason that MPI_Startall()
>> should change them -- hence, there's no need to re-assign the same
>> values back to the fortran array after the C call.
>
> The way our PML are designed, we might generate new requests for the
> MPI_Startall call. We allow the user to start multiple time the same
> requests, without having to wait for them to finish completely...
> There is the trick :) Here completely means they have to be MPI
> completed but not PML completed. If they are PML and MPI completed
> then we will reuse the same request, but if they are not PML
> completed but are MPI completed then we generate a new request and
> let the old one in the limbo. The old one will be freed, once the PML
> completion function is called.
>
> Now, that work nicely for C & C++, as the input of the MPI_Startall
> is an array of pointers. The problem with Fortran, is the the old
> request will have a f_to_c value, while the new request will not (as
> we set this value on the first call to f2c function). That's why the
> -32K value shows up in his output. By forcing the f2c conversion at
> the end of MPI_Startall, I make sure that the new requests that we
> return to the users are correctly registered in the f2c framework.
>
>>
>> Specifically: the requests are not INOUT parameters. Unless I'm
>> missing something, this commit should be backed out -- the problem
>> that Tim Campbell is running into must be something else.
>
> I checked the standard and the request array is marked as INOUT. I
> didn't check how it is marked on our files, but the standard is clear
> about it.
>
>>
>> Did we get his test program?
>
> Absolutely. It works like a charm.
>
> george.
>
>>
>>
>>
>> On Jan 11, 2007, at 3:39 AM, bosilca_at_[hidden] wrote:
>>
>>> Author: bosilca
>>> Date: 2007-01-11 03:39:42 EST (Thu, 11 Jan 2007)
>>> New Revision: 13079
>>>
>>> Modified:
>>> trunk/ompi/mpi/f77/startall_f.c
>>>
>>> Log:
>>> Once we start the C requests we have to put back their f_to_c index
>>> in the fortran array, as we might get new C requests from the
>>> startall
>>> function.
>>>
>>>
>>> Modified: trunk/ompi/mpi/f77/startall_f.c
>>> ====================================================================
>>> =
>>> =
>>> ========
>>> --- trunk/ompi/mpi/f77/startall_f.c (original)
>>> +++ trunk/ompi/mpi/f77/startall_f.c 2007-01-11 03:39:42 EST (Thu,
>>> 11 Jan 2007)
>>> @@ -75,10 +75,13 @@
>>> return;
>>> }
>>>
>>> - for (i = 0; i < *count; i++) {
>>> + for(i = 0; i < *count; i++ ) {
>>> c_req[i] = MPI_Request_f2c(array_of_requests[i]);
>>> }
>>>
>>> *ierr = OMPI_INT_2_FINT(MPI_Startall(OMPI_FINT_2_INT(*count),
>>> c_req));
>>> + for( i = 0; i < *count; i++ ) {
>>> + array_of_requests[i] = MPI_Request_c2f(c_req[i]);
>>> + }
>>> free(c_req);
>>> }
>>> _______________________________________________
>>> svn-full mailing list
>>> svn-full_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
>>
>>
>> --
>> Jeff Squyres
>> Server Virtualization Business Unit
>> Cisco Systems
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems