[mpi-21] Ballot 4 proposal: INOUT arguments

[Jeff Squyres]

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