On Sep 21 2012, Jed Brown wrote:

On Thu, Sep 20, 2012 at 12:14 PM, Jeff Hammond <[email protected]>wrote:

...

I would like MPI_(I)RECV_REDUCE, which - as you might guess - does a reduction to the receive buffer instead of a simple write. This allows one to avoid having to manually buffer incoming messages to be reduced at the receiver. Torsten and I have discussed it and it seems there are at least a few use cases.

If you do this, _please_ allow a user-defined MPI_Op to be used in the reduction (i.e., don't cripple it like one-sided).

On the contrary - that is essential for any kind of sane specification or implementation of MPI_Irecv_reduce, just as it is for one-sided. Sorry, but that's needed to get even plausible conformance with any of the languages MPI is likely to be used from. MPI_Recv_reduce doesn't have the same problems. The point is that none of them allow more-or-less arbitrary functions to be called asynchronously, and that has been horribly sick in every modern system that I have looked into in any depth. It used to work on some mainframes, but hasn't worked reliably since. That is precisely why POSIX has deprecated calling signal handlers asynchronously. Please don't perpetrate another feature like passive one-sided! Even doing it for just built-in types is problematic on some systems, just as it is for one-sided. I doubt that there are many such systems currently in use outside the embedded arena, but there may be some there, and they may well return to general computing. A much better idea would be to drop MPI_Irecv_reduce and consider just MPI_Recv_reduce. Regards, Nick Maclaren.