[Mpi-forum] Question about MPI_Alloc_mem

Thu Oct 15 12:20:03 CDT 2020

Just implement MPI allocation sanity once and forget about it :-)

#include <mpi.h>
void * MPIX_Malloc(MPI_Aint size, MPI_Info info, int * status)
{
  void * ptr = NULL;
  *status = MPI_Alloc_mem(size, info, &ptr);
  return ptr;
}

int MPIX_Free(void * ptr)
{
  return MPI_Free_mem(ptr);
}

Jeff

On Wed, Oct 14, 2020 at 12:53 PM Skjellum, Anthony via mpi-forum <
mpi-forum at lists.mpi-forum.org> wrote:

> Bill, I thank you much for your input too.
>
> POSIX has no problem making you do the cast in C 🙂
>
> *int posix_memalign(void ****memptr**, size_t* *alignment**, size_t* *size**);*
>
> I get why its that way now in MPI, I still don't like it 🙂
>
> Tony
>
> cf,
> https://linux.die.net/man/3/posix_memalign
> posix_memalign(3): allocate aligned memory - Linux man page
> <https://linux.die.net/man/3/posix_memalign>
> The function posix_memalign() allocates size bytes and places the address
> of the allocated memory in *memptr. The address of the allocated memory
> will be a ...
> linux.die.net
>
>
>
>
>
> Anthony Skjellum, PhD
>
> Professor of Computer Science and Chair of Excellence
>
> Director, SimCenter
>
> University of Tennessee at Chattanooga (UTC)
>
> tony-skjellum at utc.edu  [or skjellum at gmail.com]
>
> cell: 205-807-4968
>
>
> ------------------------------
> *From:* William Gropp <wgropp at illinois.edu>
> *Sent:* Wednesday, October 14, 2020 3:48 PM
> *To:* Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
> *Cc:* Rolf Rabenseifner <rabenseifner at hlrs.de>; Skjellum, Anthony <
> Tony-Skjellum at utc.edu>
> *Subject:* Re: [Mpi-forum] Question about MPI_Alloc_mem
>
> 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  [or skjellum at gmail.com]
> cell: 205-807-4968
>
> ------------------------------
> *From:* mpi-forum <mpi-forum-bounces at lists.mpi-forum.org> on behalf of
> Rolf Rabenseifner via mpi-forum <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>
> *Cc:* Rolf Rabenseifner <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>
> > To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> > Cc: "Anthony Skjellum" <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 <skjellum at gmail.com> | skjellum at gmail.com ]
> > Cell: +1-205-807-4968
> >
> >
> >
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
> --
> Dr. Rolf Rabenseifner . . . . . . . . . .. email 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 .
> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>

-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20201015/07a52b76/attachment-0001.html>