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 < [email protected]> 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)
[email protected] [or [email protected]]
cell: 205-807-4968
------------------------------ *From:* William Gropp <[email protected]> *Sent:* Wednesday, October 14, 2020 3:48 PM *To:* Main MPI Forum mailing list <[email protected]> *Cc:* Rolf Rabenseifner <[email protected]>; Skjellum, Anthony < [email protected]> *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 < [email protected]> 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) [email protected] [or [email protected]] cell: 205-807-4968
------------------------------ *From:* mpi-forum <[email protected]> on behalf of Rolf Rabenseifner via mpi-forum <[email protected]> *Sent:* Wednesday, October 14, 2020 1:32 PM *To:* Main MPI Forum mailing list <[email protected]> *Cc:* Rolf Rabenseifner <[email protected]> *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" <[email protected]> To: "Main MPI Forum mailing list" <[email protected]> Cc: "Anthony Skjellum" <[email protected]> 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:[email protected] <[email protected]> | [email protected] ] Cell: +1-205-807-4968
_______________________________________________ mpi-forum mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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 [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpi-forum _______________________________________________ mpi-forum mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
_______________________________________________ mpi-forum mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
-- Jeff Hammond [email protected] http://jeffhammond.github.io/