This is true for dynamic memory allocation but what prevents me
from declaring a variable such as
and sending a message such as
MPI_Send( &MyBuffer, 1, MPI_CHAR, 1,1, MPI_COMM_WORLD );
This isn't a problem so now what if we wish to do something
similar with a put/get (using memcpy() like parameters)
MPI_Put( &DestBuff, &MyBuffer, sizeof(char) * 1); ?
Now we have a possible alignment problem.
-] > > This is trivial for both users and implementations to check.
-] > Fooey. I shouldn't have to.
-] > --Dennis
-] I agree.
I agree as well (from the users' point of view).
Thinking about how to implement it on an architecture that only
allows put/get -s on X-bit boundaries gets tough. For data not
aligned on X-bit boundaries, 1-sided suddenly becomes 2-sided
which sort of steps all over the whole idea behind there being
This brings up the point of "Well, let's just limit it to the worst
case alignment among the platforms." This would imply 64-bit
alignment but wait, there are machines that can't do shared
memory put/get -s at all so the worst case is no 1-sided at all.
This approach would mean that 1-sided should actually not be
in the standard.
Personally, I can see where 1-sided could be good and where
it can be bad. On one of the platforms that I use, X-bit alignment
is a problem and on another it isn't. In both cases, I can see how
I would implement it. If X-bit alignment is mandated and it is
smaller than what the machine can do in hardware, 1-sided would
become 2-sided and be as slow as Christmas. It would basically
become an MPI_Send but with a special packet mode
that the code in the MPI_Recv on the other side would recognize
and memcpy() it to a buffer (handle?) specified in the message and
previously allocated using an MPI_RMA_MALLOC (yes I am
stressing that function name) so that the code would know that it was
indeed a valid address. Of course, this is no longer a 1-sided
communication and in fact, it will be kinda slow - defeating all the
purposes/advantages of 1-sided communications in one fell swoop.