[Mpi-forum] Discussion points from the MPI-<next> discussion today

[Jed Brown]

On Fri, Sep 21, 2012 at 1:19 PM, N.M. Maclaren <nmm1 at cam.ac.uk> wrote:

> No, they most definitely do NOT apply to MPI_Irecv, because it doesn't
> call user code.  I accept that they apply to MPI_Ireduce, though it
> could be argued not to, because there are a lot of optimisations of that
> that do not involve calling a user-defined operator except at the wait.
> And MPI could fix its current languages standard incompatibility by
> specifying that.
>

 The natural semantics of MPI_Irecv_reduce() say nothing about the
implementation making progress while application control flow is not in the
MPI stack. When it's in the stack, it's the same situation as collectives
(blocking or non).

As a separate matter, to enable more asynchronous progress while the
application is busy in user code, MPI_Ops could have an attribute
indicating that they were safe to call from a different thread (the
implementation's comm thread). This need not even be a standardized thing.
Note that C11 and C++11 define memory models.


> But, even if they do, does making an error once justify making it again?
>

Oops, evidently MPI-1 made a mistake of making MPI_Op extensible. We would
be so much better off if it just plain wasn't possible to MPI_Allreduce a
quad precision number. Those pesky users, give them an inch and they'll go
off and build something useful. ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20120921/3bb28817/attachment-0001.html>