[mpich-discuss] MPI_Get on the same memory location

[Brian Van Straalen]

Is there a significant cost to have the MPI implementation provide a check for aliasing?

int bytes;MPI_Aint N;
MPI_Type_size(type,bytes);
N=bytes*(MPI_Aint)n; /* most functions need to compute these two terms already anyways */
assert(s2>s1?s1+N>s2:s2+N>s1)

For properly reentrant functions this could prevent many bugs (I had noticed this was in the MPIR functions in the OP).

It would make the statement "Unless specified otherwise, an argument of type OUT or type INOUT cannot be aliased with any other argument passed to an MPI procedure.” a nice hard rule that you catch earlier in the call graph.

Brian

On Aug 22, 2014, at 7:56 AM, Balaji, Pavan <balaji at anl.gov> wrote:

> 
> That’s not “aliased” (as per the MPI standard), since the input and output buffers are not overlapping (I would have preferred saying “overlapping” to “aliased”).
> 
> Note that the example in the standard that shows overlapping uses copyIntBuffer(a,b,7), not copyIntBuffer(a,b,3).
> 
>  — Pavan
> 
> On Aug 22, 2014, at 9:37 AM, Michael L. Stokes <Michael.Stokes at uah.edu> wrote:
> 
>> The MPI spec you reference gives an example of aliasing (bottom p.10, top p.11).  Would the following also
>> be considered aliasing?
>> 
>> #include <stdio.h>
>> #include <stdlib.h>
>> 
>> void copyIntBuffer( int *pin, int *pout, int len ) {
>>  int i;
>>  for(i=0; i<len; ++i)
>>      *pout++ = *pin++;
>> };
>> 
>> int main() {
>>  int array[10]={0,1,2,3,4,5,6,7,8,9};
>>  int *a = &array[0];
>>  int *b = &array[3];
>>  copyIntBuffer(a,b,3);
>>  return 0;
>> }
>> 
>> It is my belief that a definition of a term is much better than an example, albeit more difficult.
>> 
>> My $.05
>> Mike
>> 
>> 
>> On 08/22/2014 08:25 AM, Carsten Clauss wrote:
>>> MPI-3, Section 2.3, page 10: "Unless specified otherwise, an argument of type OUT or type INOUT cannot be aliased with any other argument passed to an MPI procedure."
>>> 
>>> Cheers,
>>> Carsten
>>> 
>>> On 08/22/2014 03:10 PM, Balaji, Pavan wrote:
>>>> 
>>>> On Aug 22, 2014, at 7:59 AM, Balaji, Pavan <balaji at anl.gov> wrote:
>>>> 
>>>>> On Aug 21, 2014, at 8:42 PM, Nick Radcliffe <nradclif at cray.com> wrote:
>>>>> 
>>>>>>> If buffers overlap, use memmov and not memcpy:
>>>>>> 
>>>>>> Good point, you would have to use memmov in general for overlapping source and target buffers. I was thinking of the special case where the source and target buffers are identical.
>>>>>> 
>>>>>>> I don’t think so.  It’s an incorrect program to get from a buffer to itself.  MPICH is being helpful is catching this user error.
>>>>>> 
>>>>>> Do you know where in the standard this is specified? I'm having trouble finding it.
>>>>> 
>>>>> The parameter in PUT is a “const void *”.  It’s read-only for MPI.
>>>> 
>>>> It’s less clear for GET, but the standard says it’s equivalent to sending and receiving, which should imply overlapping buffers is invalid.  Either way, I can’t imagine that not being the intention of the RMA working group (I’m a part of it).
>>>> 
>>>> In MPI-2, this was not a problem at all since we couldn’t send data from the local public window to a remote public window (two simultaneous locks were not allowed; FENCE didn’t allow load/store and PUT/GET in the same epoch, etc.).  In MPI-3 we allowed this, but forgot to make it clear that they shouldn’t overlap.
>>>> 
>>>> We should try to make it clearer in the standard, though I don’t think it’s valid even in MPI-3.
>>>> 
>>>>  — Pavan
>>>> 
>>>> -- 
>>>> Pavan Balaji  ✉️
>>>> http://www.mcs.anl.gov/~balaji
>>>> 
>>>> _______________________________________________
>>>> discuss mailing list     discuss at mpich.org
>>>> To manage subscription options or unsubscribe:
>>>> https://lists.mpich.org/mailman/listinfo/discuss
>>>> 
>>> 
>> 
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
> 
> --
> Pavan Balaji  ✉️
> http://www.mcs.anl.gov/~balaji
> 
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss

Brian Van Straalen         Lawrence Berkeley Lab
BVStraalen at lbl.gov         Computational Research
(510) 486-4976             Division (crd.lbl.gov)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20140822/b907da6c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20140822/b907da6c/attachment.sig>