On Wed, 30 Jan 2008 21:34:31 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote:

1. Why do we need to indicate the INOUT status of the back-end MPI object in the language neutral bindings? All the bindings -- regardless of language -- only deal with the MPI handles, not the back- end MPI objects.

2. Adding qualifiers on what is supposed to happen to the back-end MPI object would seem to require additional semantics on the back-end MPI object. Should we really be specifying what the implementation must/ must not do with the back-end MPI object? Who benefits from that?

After all the MPI_BOTTOM discussion and not knowing what future languages will bring, I didn't want to remove existing information from the standard. An opaque object in MPI consists always of two things: the handle and the object itself. The language independent interface should reflect this. I thought that especially for the const discussion it would be good to see the IN for the handle. For future HPCS languages, it may be also necessary see the INOUT for the object itself. Best regards Rolf

On Jan 29, 2008, at 12:07 PM, Rolf Rabenseifner wrote:

...

Proposal: The current text in MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:

There is one special case — if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call, then the argument is marked OUT. It is marked this way even though the handle itself is not modified — we use the OUT attribute to denote that what the handle references is updated. Thus, in C++, IN arguments are either references or pointers to const objects.

but should read:

There is one special case — if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call but the handle itself is not modified , then the argument is marked IN/INOUT. We use the first part (IN) to specify the use of the handle and the second part (INOUT) to specify the use of the opaque object. Thus, in C++, IN arguments are either references or pointers to const objects, IN/INOUT arguments are references to const handles to non-const objects.

In all reoutines mentioned in the clarification below, the INOUT handle declaration (in MPI-2.0) and the IN handle declaration (in MPI-1.1) ist modified into a IN/INOUT handle declaaration. ____________________________

Rationale for this proposal:

I have checked the total MPI 1.1 and 2.0 standard to find all routines with an argument specification according to the following declaration pattern:

Language independent interface: INOUT handle C interface MPI_handletype handle

We can find this pattern only in MPI-2.0 at following routines:

MPI_INFO_SET / _DELETE MPI_xxxx_SET_ERRHANDLER with xxxx=COMM / TYPE / WIN MPI_GREQUEST_COMPLETE MPI_xxxx_SET_NAME with xxxx=COMM / TYPE / WIN MPI_xxxx_SET_ATTR with xxxx=COMM / TYPE / WIN MPI_xxxx_DELETE_ATTR with xxxx=COMM / TYPE / WIN MPI_FILE_SET_SIZE / _PREALLOCATE / _SET_INFO / _SET_VIEW MPI_FILE_WRITE_AT / _WRITE_AT_ALL / _IWRITE_AT MPI_FILE_READ / _READ_ALL / _WRITE / _WRITE_ALL MPI_FILE_IREAD / _IWRITE MPI_FILE_SEEK MPI_FILE_READ_SHARED / _WRITE_SHARED MPI_FILE_IREAD_SHARED / _IWRITE_SHARED MPI_FILE_READ_ORDERED / _WRITE_ORDERED MPI_FILE_SEEK_SHARED MPI_FILE_WRITE_AT_ALL_BEGIN / MPI_FILE_WRITE_AT_ALL_END MPI_FILE_READ_ALL_BEGIN / MPI_FILE_READ_ALL_END MPI_FILE_WRITE_ALL_BEGIN / MPI_FILE_WRITE_ALL_END MPI_FILE_READ_ORDERED_BEGIN / MPI_FILE_READ_ORDERED_END MPI_FILE_WRITE_ORDERED_BEGIN / MPI_FILE_WRITE_ORDERED_END MPI_FILE_SET_ATOMICITY / _SYNC

All these routines keep the handle itself unchanged, but the opaque object is modified in a way, that with oother MPI routines this change can be detected. For example, an attribute is cached or changed, a file pointer is moved, the content of a file was modified.

The current text in MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:

There is one special case — if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call, then the argument is marked OUT. It is marked this way even though the handle itself is not modified — we use the OUT attribute to denote that what the handle references is updated. Thus, in C++, IN arguments are either references or pointers to const objects.

With this definition (that I want to change later on) the use of INOUT is correct.

In MPI-1.1 we have several of such routines, but in all cases, the handle is declared only as IN.

I hope, I could find all of them:

MPI_ATTR_PUT / _ DELETE MPI_ERRHANDLER_SET (these routines are now deprecated, but compare with use of INOUT in MPI_COMM_SET_ATTR and MPI_COMM_DELETE_ATTR in MPI-2.0)

The following proposal should remove this inconsistency and should be a basis for correct definition of const. ____________________________

I hope, with this proposal, the INOUT handle problem can be really solved.

Best regards Rolf

Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) _______________________________________________ mpi-21 mailing list mpi-21_at_[hidden] http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21

-- Jeff Squyres Cisco Systems

_______________________________________________ mpi-21 mailing list mpi-21_at_[hidden] http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21

Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)