[Mpi3-rma] Target displacement sign issue

Jim Dinan dinan at mcs.anl.gov
Wed Sep 5 09:13:37 CDT 2012


Hi Hubert,

If I understand this correctly, then one would no longer be able to cast 
an MPI_Aint back to a pointer.  We would have to add another routine, 
MPI_Get_pointer_dynamic() to do this conversion.

  ~Jim.

On 9/4/12 6:25 PM, Hubert Ritzdorf wrote:
>
> Hi,
>
> Possibly another solution:
>
> (*) Let MPI_AINT_MAX the maximal value of MPI_Aint variable
> (*) Let the window_base of a window created by MPI_WIN_CREATE_DYNAMIC
>      be MPI_AINT_MAX + 1
> (*) Define a new function MPI_Get_address_dynamic returning the
>      address of a location relative to MPI_AINT_MAX + 1
> (*) Remove the non-negative qualification in the description
>      of target_disp in MPI_{Put/Get/Accumulate/...).
>
> Hubert
>
>> -----Original Message-----
>> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
>> bounces at lists.mpi-forum.org] On Behalf Of Hubert Ritzdorf
>> Sent: Tuesday, September 04, 2012 7:23 PM
>> To: MPI 3.0 Remote Memory Access working group
>> Subject: Re: [Mpi3-rma] Target displacement sign issue
>>
>> Hi,
>>
>> MPI_Get_address returns an MPI_Aint which is signed.(integer).
>>
>> C:
>> MPI_Aint's may be used in Reduce Operations with Min/Max
>> or the application can internally use min/max computations.
>> Can anybody guarantee that applications don't perform
>> min/max operations on these displacements (which results in different
>> results for unsigned and signed variables) or use derived values of these
>> displacements in other signed/unsigned significant cases.
>>
>> Fortran:
>> MPI_BOTTOM is a variable in a common block/module. Thus,
>> MPI_Get_address might really return a signed integer (depending on the
>> compiler).
>> Fortran doesn't have unsigned integers and cannot handle them.
>> Thus, the non-negative integer specification for target_disp in
>> MPI_{Put/Get/Accumulate/...)
>> might be incorrect for Fortran and MPI_Win_Create_dynamic().
>>
>> Hubert
>> ________________________________________
>> From: mpi3-rma-bounces at lists.mpi-forum.org [mpi3-rma-bounces at lists.mpi-
>> forum.org] on behalf of Jim Dinan [dinan at mcs.anl.gov]
>> Sent: Tuesday, September 04, 2012 5:10 PM
>> To: mpi3-rma at lists.mpi-forum.org
>> Subject: Re: [Mpi3-rma] Target displacement sign issue
>>
>> Hi All,
>>
>> This is an important issue that we need to resolve before releasing the
>> 3.0 spec.  Please take a look and send feedback.
>>
>> Dave has voiced a concern that the implicit type conversion in my
>> proposed text below may not be portable.  If anyone has more experience
>> with this aspect (signed->unsigned conversion) of C/Fortran/etc type
>> systems, please chime in.
>>
>>    ~Jim.
>>
>> On 8/28/12 2:29 PM, Jim Dinan wrote:
>>> Hi All,
>>>
>>> Here is the suggested change to address this issue.  In the paragraph on
>>> page 425, line 1, add the bracketed sentence:
>>>
>>> In the case of a window created with MPI_WIN_CREATE_DYNAMIC, the
>>> target_disp for all RMA functions is the address at the target; i.e.,
>>> the effective window_base is MPI_BOTTOM and the disp_unit is one. [Thus,
>>> for dynamic windows, the target_disp argument to all RMA functions in
>>> interpreted as unsigned.] Users should use MPI_GET_ADDRESS at the target
>>> process to determine the address of a target memory location and
>>> communicate this address to the origin process.
>>>
>>>     ~Jim.
>>>
>>> On 8/28/12 9:46 AM, Jim Dinan wrote:
>>>> Hi All,
>>>>
>>>> Currently, target displacements in put/get/acc/etc are defined to be
>>>> non-negative integers of type, MPI_Aint.  MPI_Aint is defined to be a
>>>> signed integer.  However, displacements associated with dynamic windows
>>>> are addresses (unsigned) and can range into the space of negative
>>>> integers.
>>>>
>>>> It seems like the least impact change would be to add a special case
>>>> that the displacement argument will be interpreted as unsigned for
>>>> dynamic windows.  Changing the interface to take an 'unsigned MPI_Aint'
>>>> would be the most clear (and preserve the existing and intended new
>>>> semantics), but would break backward compatibility.
>>>>
>>>> Interested to hear your thoughts.
>>>>
>>>>    ~Jim.
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>
>>
>>   Click
>> https://www.mailcontrol.com/sr/O6SiJI5AP4bTndxI!oX7Up2F0f+S6NySj!qlvEoKFyZ
>> NTFyVkk9WjRzJbmnfHdyw83VGVWKbSfC8ewgPpp7kgg==  to report this email as
>> spam.
>>
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>



More information about the mpiwg-rma mailing list