[mpiwg-rma] MPI_Win_create on unmapped memory?

[maik peterson]

jeff, in mpi you can put in what you like, the result is always the same:
unexpected fiddle-faddle. mp

2018-01-04 0:23 GMT+01:00 Jeff Hammond <jeff.science at gmail.com>:

>
>
> On Wed, Jan 3, 2018 at 1:07 AM, Thomas Jahns <jahns at dkrz.de> wrote:
> >
> > On 01/02/18 20:52, Jeff Hammond wrote:
> >>
> >> If a user passes a (base,size) pair that corresponds to a range of
> addresses that are not allocated and/or mapped, is that a correct MPI
> program?
> >
> >
> > Such a thing wouldn't be a valid object pointer in C/C++ or a variable
> in Fortran, i.e. both languages prohibit this.
>
> Which of the following MPI_Win_create calls are not using a valid object
> pointer according to ISO C and/or C++?
>
> char a = '\0';
>
> int main() {
> ..
> char * x = malloc(1);
> MPI_Win_create(x,1000,1,MPI_INFO_NULL,MPI_COMM_WORLD,&win);
> ...
> MPI_Win_create(&a,1000,1,MPI_INFO_NULL,MPI_COMM_WORLD,&win);
> ..
> foo(); // compiler cannot prove this function does not call
>          // mmap(0x10000, 1, PROT_READ|PROT_WRITE,
> MAP_FIXED|MAP_ANONYMOUS, -1, 4096);
> ..
> MPI_Win_create(0x10000,1000,1,MPI_INFO_NULL,MPI_COMM_WORLD,&win);
> ..
> }
>
> >> The only text I can find that implies that buffers passed to
> MPI_Win_create have to be allocated is the following, assuming that one
> interprets "existing memory" this way.
> >>
> >> "Each process specifies a window of existing memory that it exposes to
> RMA accesses by the processes in the group of comm." (MPI 3.1 11.2.1)
> >
> >
> > Since MPI is a library standard I would still expect all the guarantees
> of the language standards involved to hold and the above to only be an
> additional clarification?
>
> It's only a clarification.  However, I don't think it's a good idea for
> the MPI standard to punt this off on ISO C, because not every
> implementation of MPI is an ISO C language lawyer, and very few users are.
>
> >> The Fortran-specific text is similarly suggestive, but it only says
> that a user can pass a simply contiguous array, not that such a thing is
> required.
> >>
> >> "In Fortran, one can pass the first element of a memory region or a
> whole array, which must be ‘simply contiguous’"
> >
> >
> > That's most probably because of the Fortran storage association
> "feature" which is more about how arrays were passed in pre-Fortran 90
> times, i.e. it's legal for a caller C to pass some array element A(i) to a
> subprogram P accepting an array argument B(*) provided the effective size
> (that is the indices of B used in P match to valid indices of A).
>
> The widespread use of MPI in the context of non-strict Fortran is a
> particularly good reason to clarify this ourselves rather than rely on ISO
> Fortran.  As has been discussed many times in the passed, MPI relies on
> extensions and/or implementation-specific behavior with Fortran through the
> latest standard.  Only with Fortran 2018 will this situation disappear.
>
> Jeff
>
> > Regards, Thomas
> > --
> > Thomas Jahns
> > HD(CP)^2
> > Abteilung Anwendungssoftware
> >
> > Deutsches Klimarechenzentrum GmbH
> > Bundesstraße 45a • D-20146 Hamburg • Germany
> >
> > Phone:  +49 40 460094-151 <+49%2040%20460094151>
> > Fax:    +49 40 460094-270 <+49%2040%20460094270>
> > Email:  Thomas Jahns <jahns at dkrz.de>
> > URL:    www.dkrz.de
> >
> > Geschäftsführer: Prof. Dr. Thomas Ludwig
> > Sitz der Gesellschaft: Hamburg
> > Amtsgericht Hamburg HRB 39784
> >
> >
> > _______________________________________________
> > mpiwg-rma mailing list
> > mpiwg-rma at lists.mpi-forum.org
> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma
>
>
>
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-rma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20180104/80839b55/attachment.html>