[mpi-21] Ballot 4 proposal: INOUT arguments

Tue Feb 5 19:55:41 CST 2008

On Feb 5, 2008, at 12:23 PM, Erez Haba wrote:

> Who is the "user" of the language independent IN OUT attributes?  
> Don't you end-up looking at the lang dependent binding?

Exactly!  The *bindings* are dealing with the handle, not the object.   
There is no point in having the bindings imply what happens to the  
back-end object.

Denoting an MPI handle as INOUT because you can test the handle later  
for an observable change (what I have been calling an "explicit"  
change) is already stated explicitly in the description of all the  
functions in question (e.g., MPI_COMM_SET_NAME).  It doesn't seem that  
marking the handle INOUT adds any value to the explanation of these  
functions.

In short: I think that this handle exception language should go away,  
and the IN, OUT, INOUT descriptors should only pertain to the behavior  
of the handles.  This has the added benefit of making mapping to the  
language-specific bindings much more clear.

>
>
> -----Original Message-----
> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]]  
> On Behalf Of Rolf Rabenseifner
> Sent: Tuesday, February 05, 2008 1:40 AM
> To: Mailing list for discussion of MPI 2.1
> Subject: Re: [mpi-21] Ballot 4 proposal: INOUT arguments
>
> Jeff,
>
> the currently existing INOUT for the handle/object arguments
> in the routine listed in a previous mail from me indicates
> a change of the object that can be inquired later on by
> an MPI inquiry function. What an MPI implementation
> is doing internally is not shown by these interface definitions.
>
> I'm reporting only the obviouus background of the wording
> in the current MPI 1.1 and MPI 2.0 standard.
>
> And there is an inconsistency with the three MPI 1.1 definitions:
> MPI_ATTR_PUT, MPI_ATTR_DELETE, MPI_ERRHANDLER_SET
>
> There are three options to solve it:
> (all proposal will change the language independent routine definitions
>  but none of the language bindings, and therefore, they do not have
>  any real impact on the existing implementations nor on MPI  
> applications)
>
> - modify all such definitions into OUT (will change the MPI 1.1  
> routine
>   language independent definitions)
> - modify all such definitions into IN/INOUT (wiil change in MPI 1.1  
> and 2.0)
> - modify all such definitions into IN (will change the MPI 2.0 routine
>   language independent definitions)
>
> I will prpose all three options to the MPI Forum and the Forum has  
> to decide
> which options is the best.
>
> Best regards
> Rolf
>
>
> On Mon, 4 Feb 2008 21:15:13 -0500
> Jeff Squyres <jsquyres_at_[hidden]> wrote:
>> On Jan 31, 2008, at 10:26 AM, Rolf Rabenseifner wrote:
>>
>>>> If we also want to specify the behavior of the object, then a)  
>>>> that's
>>>> a huge change (and not one that I'm convinced we need), and b) we
>>>> need
>>>> to add a second IN/OUT/INOUT to every language-neutral binding
>>>> representing what happens to the object.  Adding it to only a few  
>>>> of
>>>> the bindings doesn't seem consistent to me.
>>>
>>> The trick is, that we have this problem only with the
>>> handle/object arguments.
>>> In most cases we have
>>> - IN/IN which is abbreviated with IN, e.g., MPI_Send(IN comm), or
>>> - OUT/OUT which is abbreviated with OUT, e.g., in MPI_Isend(OUT rq),
>>> or
>>> - INOUT/INOUT which is abbreviated with INOUT,
>>> e.g. in MPI_Type_commit(INOUT datatype)
>>>
>>> The change, I'm proposing is based on your wish to see the IN for
>>> the handles that are kept constant.
>>> Changing no words would continue to show the INOUT
>>> for the objects itself (that's the way MPI-2 was written).
>>>
>>> I would not say, that it is a huge change to add the handle IN
>>> information to all the interfaces.
>>> It is not huge, although there are more routines affected
>>> (also many MPI_FILE routines) as you have mentioned in your
>>> first mails.
>>
>> I'm not sure that this is right, though -- my point is that there are
>> many functions with IN handles that *do* [implicitly] change the
>> underlying object (e.g., MPI_SEND can change the communicator
>> object).  Specifically: I do not agree that everywhere we see "IN" in
>> the current standard means that the object cannot change.
>>
>> Aside from the exception statement, we have not stipulated the
>> behavior of the back-end MPI objects.  I think that's a good thing.
>>
>> I guess what I don't understand is: why is it useful to specify the
>> implementation of the back-end MPI objects?
>>
>> FWIW: the only thing that matters to the bindings is the behavior of
>> the handle.
>>
>>>
>>> Okay?
>>>
>>> Best regards
>>> Rolf
>>>
>>> On Thu, 31 Jan 2008 09:56:48 -0500
>>> Jeff Squyres <jsquyres_at_[hidden]> wrote:
>>>> On Jan 31, 2008, at 8:46 AM, Rolf Rabenseifner 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.
>>>>
>>>> I agree.
>>>>
>>>>> For future HPCS languages, it may be
>>>>> also necessary see the INOUT for the object itself.
>>>>
>>>> I guess my point is that the language bindings don't specify  
>>>> anything
>>>> about the object itself anywhere else.
>>>>
>>>> If we also want to specify the behavior of the object, then a)  
>>>> that's
>>>> a huge change (and not one that I'm convinced we need), and b) we
>>>> need
>>>> to add a second IN/OUT/INOUT to every language-neutral binding
>>>> representing what happens to the object.  Adding it to only a few  
>>>> of
>>>> the bindings doesn't seem consistent to me.
>>>>
>>>> --
>>>> 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)
>>> _______________________________________________
>>> 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)
> _______________________________________________
> mpi-21 mailing list
> mpi-21_at_[hidden]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
>
> _______________________________________________
> mpi-21 mailing list
> mpi-21_at_[hidden]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21

-- 
Jeff Squyres
Cisco Systems