[MPI3 Fortran] Request for a straw vote.

Bill Long longb at cray.com
Wed Jun 10 18:40:14 CDT 2009



Craig Rasmussen wrote:
> 
> On Jun 10, 2009, at 11:08 AM, Hubert Ritzdorf wrote:
> 
>> Craig Rasmussen wrote:
>
>>> 12. Q: Is it an error if the user gives a non-contiguous buffer to a 
>>> choice argument as it is for C?
>>>    A: Yes.
>>>    Unresolved issue:  Should the vendor be required to catch the 
>>> error as always checking the argument is a performance issue
>> No; The MPI library has to support this and the MPI forum has to 
>> define how the
>> non-contiguous buffer has to be interpreted.
> 
> A note to everyone not at the MPI Forum meeting.  There seems to be a 
> consensus forming around having the MPI implementors doing the "right" 
> thing with regards to noncontiguous memory.
> 

Doing the "right" thing could be simpler if the request argument were a 
small structure instead of a simple integer. Maybe TYPE MPI_Request. 
The first component of the struct would be the same as the current 
integer. That way the address of the struct could be passed to the C 
routine as is now the case and still work.  The other components would 
be ignored by the lower level routine, and contain the information used 
to control the copy-in and copy-out processes inside wrappers for the 
non-blocking routines.  The same information is available to the WAIT 
routine later. There it can be used to decide if a temp copy was 
allocated (non-NULL address in the temp component), and if a copy-out is 
needed (non-NULL address for the descriptor for the original actual 
argument). This allows deferring the copy-out and freeing of the temp to 
the WAIT routine, solving the classic "copy-in/copy-out" problem that 
can afflict the non-blocking routines now.

Cheers,
Bill



-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120





More information about the mpiwg-fortran mailing list