It is proposed that
(a) text be added to the description of MPI_RMA_ALLOC() which states
both 2-sided and 1-sided communication could potentially benefit
from using the memory returned by this function.
(b) the 'bytes' argument to MPI_RMA_ALLOC() be replaced with 'count'
(c) MPI_RMA_ALLOC() be made collective.
(d) MPI_RMA_ALLOC() and MPI_RMA_FREE() be moved out of the 1-sided
chapter and renamed as MPI_MEM_ALLOC() and MPI_MEM_FREE(). (For
lack of a better alternative, we could just move them into the
misc chapter for now.)
(a) Calling MPI_SEND() with buffers returned by this function offers a
significant opportunity for optimization on both shared memory and
distributed machines. Since we have this new function anyway, it
seems logical to take advantage of it to the fullest possible
We may or may not decide to add a new send mode in which the user
asserts that the send buffer is special; that is a seperate issue.
(b) We may have gone back and forth on this issue a few times in the
past, but if we would like to be able to use these buffers for
2-sided as well then it seems much more natural to describe the
buffer in the same way that MPI_SEND() does. Users who wish to
specify exact byte counts can use MPI_BYTE as the datatype.
(c) This follows from "Rusty's Rule", which states that more knowledge
is better. It is not necessary that each process specify identical
count and datatype arguments, but shared memory systems in particular
may need the participation of all processes in the communicator.
This possibility is already mentioned in the current draft as an
(d) This reflects the broader scope of these two functions, which are
useful for more than just RMA operations.
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-808 last Xon said, just email@example.com Mountain View, CA 94043-1389 before he died?"