[mpi-21] Ballot 4 proposal: INOUT arguments

Erez Haba erezh at [hidden]
Tue Feb 5 11:23:57 CST 2008



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

-----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



More information about the Mpi-21 mailing list