Well, actually, that is the Reader's Digest version (and a good one) of the
first couple of paragraphs of the message. And, I suggest that it's not a
bad model. But, later, I go even further, and suggest getting rid of the use
of BARRIER as well, by making GET and PUT true collective communications, just
like GATHER and SCATTER (and, in fact, close to them semantically).
>David, it would probably be useful to post some concrete examples for the
>proposed interface...
The interface to MPI_PUT would syntactically be the same as it is now, plus
one additional argument, OUT recvbuf, and minus the "increment" argument, so
it would be:
MPI_PUT(origin_addr, origin_count, origin_datatype, target_rank,
target_disp, target_count, target_datatype, recvbuf, comm).
The interface to MPI_GET would syntactically be the same as it is now, plus
one additional argument, IN sendbuf, and minus the "increment" argument, so
it would be:
MPI_GET(origin_addr, origin_count, origin_datatype, target_rank,
target_disp, target_count, target_datatype, sendbuf, comm).
The non-blocking interfaces, MPI_IPUT and MPI_IGET, would syntactically be
the same as they are now, with the same modifications.
The semantics would be the same as the current calls, except that:
(1) they would be collective -- i.e. all of the processes would need to
participate before any of them completed, and all processes would need to
specify the same calue for "target_disp"
(2) the "recvbuf" or "sendbuf" would only be significant in the "target_rank"
(aka root) process,
-- and it would be permissable for the "origin_count" argument to be zero.
At the very end of my message, I suggested that some people might desire that
there be another form of the interface which took a list of
(origin_addr, origin_count, origin_datatype)
triples in an array, and/or a list of
(target_disp, target_count, target_datatype)
triples in an array, to PUT or GET many values at one time without constructing
complex derived types.
-Dave
===============================================================================
David C. DiNucci | MRJ, Inc., Rsrch Scntst |USMail: NASA Ames Rsrch Ctr
dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Group | Moffett Field, CA 94035