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