[Mpi-forum] Question about MPI_Alloc_mem

Wed Oct 14 14:48:28 CDT 2020

My previous email (probably crossing paths with Tony’s reply) addressed most of this.  The one thing that I want to add is that the API choice made in MPI for the C binding, both in the MPI-1 attribute get functions and here, has nothing to do with the Fortran binding.  These were made to match C’s limitations on anonymous pointers, and to avoid requiring pointer casts. 

Bill

William Gropp
Director and Chief Scientist, NCSA
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign

> On Oct 14, 2020, at 2:42 PM, Skjellum, Anthony via mpi-forum <mpi-forum at lists.mpi-forum.org> wrote:
> 
> Rolf, the rationale is not clear at all to me: "to facilitate type casting" is self-understood or a canonical term of art. I've been programming in C for 40 years... and I never would write the API as we have done it there.  
> 
> For pointers, out arguments are literally truthful: void **ptr is an out argument of a void pointer, and void *ptr is an in argument of a void pointer.
> 
> {Years ago, before there was void *, we would have written char **ptr for a char out argument (and cast it to whatever type we wanted), and char *ptr for an in point argument. }
> 
> The fact that a void ** can stand in the place of a void * is clearly a weakened typing in the language, because void * can point at anything (unknown).  Since a void * is a pointer, it can also hold a pointer to a pointer to void, sure.   But the intent of the second * is to remind you that you have an out argument.  And you *must* pass a pointer to a pointer for the API to work in C.
> 
> Somehow this is helping the Fortran and C_PTR API of Fortran, as it states.  So the C API is made this way for convenience of Fortran.
> 
> The rationale shows the argument with the & to pass the pointer to the API by reference.  But, the rationale is not necessarily normative.  A reasonable person reads the standard,  sees void * and passes the baseptr without the &.  
> 
> Seems like a bad API to me.
> 
> Tony
> 
> 
> Anthony Skjellum, PhD
> Professor of Computer Science and Chair of Excellence
> Director, SimCenter
> University of Tennessee at Chattanooga (UTC)
> tony-skjellum at utc.edu <mailto:tony-skjellum at utc.edu>  [or skjellum at gmail.com <mailto:skjellum at gmail.com>]
> cell: 205-807-4968
> 
> From: mpi-forum <mpi-forum-bounces at lists.mpi-forum.org <mailto:mpi-forum-bounces at lists.mpi-forum.org>> on behalf of Rolf Rabenseifner via mpi-forum <mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>>
> Sent: Wednesday, October 14, 2020 1:32 PM
> To: Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>>
> Cc: Rolf Rabenseifner <rabenseifner at hlrs.de <mailto:rabenseifner at hlrs.de>>
> Subject: Re: [Mpi-forum] Question about MPI_Alloc_mem
>  
> Dear Tony, 
> 
> please read MPI-3.1 page 338, lines 36-41.
> Do these lines resolve your question?
> 
> Best regards
> Rolf 
> 
> ----- Original Message -----
> > From: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>>
> > To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>>
> > Cc: "Anthony Skjellum" <skjellum at gmail.com <mailto:skjellum at gmail.com>>
> > Sent: Wednesday, October 14, 2020 7:01:54 PM
> > Subject: [Mpi-forum] Question about MPI_Alloc_mem
> 
> > Folks, I know we have had this function for a long time, and I've implemented
> > ports of MPI that actually use it (e.g., with pre-pinned memory). But, I am
> > trying to understand the logic for why baseptr is passed by value, instead of
> > by reference. In C, everything is by value, so the last argument in normal C
> > programs would be void **baseptr.
> > 
> > The standard has:
> > int MPI_Alloc_mem(MPI_Aint size, MPI_Info info, void *baseptr);
> > Now, MPICC/GCC takes this with
> > void *memory = (void *)0;
> > int error = MPI_Alloc_mem(1024, MPI_INFO_NULL, &memory);
> > and you get the memory allocated properly.
> > What is more, this is incorrect:
> > int error = MPI_Alloc_mem(1024, MPI_INFO_NULL, memory);
> > although it compiles fine because that is, indeed, the API.
> > Why would we have the pointer going in by value, when it is coming out
> > as an OUT argument?
> > Isn't this plain wrong?  void **baseptr means ---> I am passing you the
> > address of a void pointer.
> > Every viable implementation must do *(void **)baseptr = ...
> > when providing the "malloc'd/special" memory.  So... why did we fudge
> > the C API.  Is there some tie-in with the Fortran API?
> > Thanks in advance,
> > Tony Skjellum
> > 
> > 
> > --
> > Anthony Skjellum, PhD
> > [ mailto:skjellum at gmail.com <mailto:skjellum at gmail.com> | skjellum at gmail.com <mailto:skjellum at gmail.com> ]
> > Cell: +1-205-807-4968
> > 
> > 
> > 
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>
> > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum>
> 
> -- 
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de <mailto:rabenseifner at hlrs.de> .
> 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 <http://www.hlrs.de/people/rabenseifner> .
> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20201014/935cc411/attachment-0001.html>