<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>So "completion" here (excerpt below) only means "will be globally visible at the first legal opportunity"?</div><div><br></div><div>I think the text should permit but not require errors to be reported during flush, to accommodate Jim's example.</div><div><br></div><div>Thanks,</div><div><br></div><div>Jeff</div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">"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."</span><br><br>Sent from my iPhone</div><div><br>On Feb 4, 2015, at 6:35 AM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 4:14 PM, Jeff Hammond <span dir="ltr"><<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How is win_flush not synchronizing? It cause global visibility of updates. I don't see how a non-synchronizing implementation could exist.<br>
<br>
Jeff<br>
<br>
Sent from my iPhone<br>
<br>
> On Feb 3, 2015, at 12:50 PM, MPI Forum <<a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a>> wrote:<br>
><br>
> #323: User-Level Failure Mitigation<br>
> -------------------------------------+-----------------------------------<br>
> Reporter: bosilca | Owner: bosilca<br>
> Type: Enhancements to standard | Status: new<br>
> Priority: Scheduled | Milestone: Future<br>
> Version: MPI 4.0 | Resolution:<br>
> Keywords: FT | Implementation status: Completed<br>
> -------------------------------------+-----------------------------------<br>
><br>
> Comment (by bouteill):<br>
><br>
> Replying to [comment:32 jhammond]:<br>
>> This means that page 5 line 11 of the latest FT proposal must be amended<br>
> somehow, as it pertains to the use of the phrase "epoch closing" (which<br>
> should be "epoch-closing", no?), unless you deliberately mean to exclude<br>
> {{{MPI_WIN_FLUSH(_LOCAL)(_ALL)}}} and {{{MPI_WIN_SYNC}}} from the list of<br>
> functions that must raise a process failure exception. And if they are<br>
> excluded, then their relationship to FT is ambiguous, since they are<br>
> neither communication operations nor epoch-closing synchronization.<br>
>><br>
>> I suppose that we should treat {{{MPI_WIN_FLUSH_LOCAL(_ALL)}}}<br>
> differently from {{{MPI_WIN_FLUSH(_ALL)}}}, since the former is a local<br>
> operation and the latter is a nonlocal one. Given that<br>
> {{{MPI_WIN_FLUSH(_ALL)}}} induce remote completion, they will detect<br>
> remote process failures and thus can be required to raise these without<br>
> introducing unreasonable overhead.<br>
><br>
> Ok, thinking more about this I came to the conclusion that the current<br>
> text is correct: WIN_FLUSH is not local, but it is ordering more than<br>
> remote completion, so it may not always detect errors. If it does (when<br>
> the particular implementation does guarantee remote completion), it will<br>
> raise an exception (as is possible in any cases), when the implementation<br>
> is not synchronizing, it will not. Mandating the raising of the exception<br>
> may make it more expensive.<br>
><br>
> We may want to add some rationale/advices to remember why we came to that<br>
> conclusion (if you agree with me here) ?<br>
><br>
> --<br>
> Ticket URL: <<a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323#comment:39" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323#comment:39</a>><br>
> MPI Forum <<a href="https://svn.mpi-forum.org/" target="_blank">https://svn.mpi-forum.org/</a>><br>
> MPI Forum<br>
_______________________________________________<br>
mpiwg-ft mailing list<br>
<a href="mailto:mpiwg-ft@lists.mpi-forum.org">mpiwg-ft@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft</a><br>
</blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>mpiwg-ft mailing list</span><br><span><a href="mailto:mpiwg-ft@lists.mpi-forum.org">mpiwg-ft@lists.mpi-forum.org</a></span><br><span><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft</a></span></div></blockquote></body></html>