So "completion" here (excerpt below) only means "will be globally visible at the first legal opportunity"? I think the text should permit but not require errors to be reported during flush, to accommodate Jim's example. Thanks, Jeff "MPI_WIN_FLUSH completes all outstanding RMA operations initiated by the calling process to the target rank on the specified window. The operations are completed both at the origin and at the target." Sent from my iPhone

On Feb 4, 2015, at 6:35 AM, Jim Dinan <[email protected]> wrote:

If flush is performed during an exclusive lock epoch, it may not need to wait for remote completion. Keep in mind that flush talks about visibility of updates, not the specific protocol that the implementation needs to use. For example, MPICH implements RMA on top of active messages that traverse ordered channels. In that scenario, flush during an exclusive lock epoch where the lock has already been acquired can be a no-op. If we required win_flush to always wait for remote completion (i.e. always notify) in the FT proposal, we would be prescribing a particular protocol, which we would like to avoid if possible.

...

On Tue, Feb 3, 2015 at 4:14 PM, Jeff Hammond <[email protected]> wrote: How is win_flush not synchronizing? It cause global visibility of updates. I don't see how a non-synchronizing implementation could exist.

Jeff

Sent from my iPhone

...

On Feb 3, 2015, at 12:50 PM, MPI Forum <[email protected]> wrote:

#323: User-Level Failure Mitigation -------------------------------------+----------------------------------- Reporter: bosilca | Owner: bosilca Type: Enhancements to standard | Status: new Priority: Scheduled | Milestone: Future Version: MPI 4.0 | Resolution: Keywords: FT | Implementation status: Completed -------------------------------------+-----------------------------------

Comment (by bouteill):

Replying to [comment:32 jhammond]:

...

This means that page 5 line 11 of the latest FT proposal must be amended somehow, as it pertains to the use of the phrase "epoch closing" (which should be "epoch-closing", no?), unless you deliberately mean to exclude {{{MPI_WIN_FLUSH(_LOCAL)(_ALL)}}} and {{{MPI_WIN_SYNC}}} from the list of functions that must raise a process failure exception. And if they are excluded, then their relationship to FT is ambiguous, since they are neither communication operations nor epoch-closing synchronization.

I suppose that we should treat {{{MPI_WIN_FLUSH_LOCAL(_ALL)}}} differently from {{{MPI_WIN_FLUSH(_ALL)}}}, since the former is a local operation and the latter is a nonlocal one. Given that {{{MPI_WIN_FLUSH(_ALL)}}} induce remote completion, they will detect remote process failures and thus can be required to raise these without introducing unreasonable overhead.

Ok, thinking more about this I came to the conclusion that the current text is correct: WIN_FLUSH is not local, but it is ordering more than remote completion, so it may not always detect errors. If it does (when the particular implementation does guarantee remote completion), it will raise an exception (as is possible in any cases), when the implementation is not synchronizing, it will not. Mandating the raising of the exception may make it more expensive.

We may want to add some rationale/advices to remember why we came to that conclusion (if you agree with me here) ?

-- Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323#comment:39> MPI Forum <https://svn.mpi-forum.org/> MPI Forum

---

mpiwg-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

_______________________________________________ mpiwg-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft