<br><font size=2 face="sans-serif">Josh </font>
<br>
<br><font size=2 face="sans-serif">Did you see this?</font>
<br>
<br><font size=2 face="sans-serif">"For example, if there were a loop
of 100 MPI_Bcast calls and on iteration 5, rank 3 uses a bad communicator,
what is the proper state?  Either a sequence number is mandated so
the other ranks hang quickly or a sequence number is prohibited so everybody
keeps going until the "end" when the missing MPI_Bcast becomes
critical.  Of course, with no sequence number, some tasks are stupidly
using the iteration n-1 data for their iteration n computation.</font><font size=3>
"</font>
<br>
<br><font size=3>If my MPI implementation is going to tell you it "</font><tt><font size=2>allows
for correct operation after returning that error class", </font></tt><font size=2 face="sans-serif">the
standard needs to tell me which behavior is "correct operation"
and what is not  "correct operation".</font>
<br>
<br><font size=2 face="sans-serif">As I mentioned to Bronis, I have no
problem with an advise to implementors urging that they at least allow
an option for continued use of libmpi, after an error returns, but  at
the users own risk.  Offhand, I cannot see any harm in urging MPI
implementors to promise that all locks will be released when a subroutine
returns non-SUCCESS.</font>
<br>
<br><font size=2 face="sans-serif">Can you give me a use case for the added
complexity of CAN_CONTINUE vs CANNOT_CONTINUE.? </font>
<br>
<br><font size=2 face="sans-serif">Consider that an error class of CAN_CONTINUE
that is returned because the MPI implementor does not really know what
"correct operation" means and decides to wing it is not very
useful.  An MPI implementor that can get in real trouble for negligence
would need to be very cautious about returning CAN_CONTINUE.</font>
<br>
<br><font size=2 face="sans-serif">Just asking the MPI implementor to refrain
from flagging the error "MPI disabled after prior error" on otherwise
correct future calls seems as good to me.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Dick Treumann  -  MPI Team
          </font>
<br>
<br><font size=2 face="sans-serif"><br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846         Fax (845) 433-8363<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Joshua Hursey <jjhursey@open-mpi.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">"MPI 3.0 Fault Tolerance and Dynamic
Process Control working Group" <mpi3-ft@lists.mpi-forum.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">09/20/2010 01:51 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Mpi3-ft] Defining the state of
MPI after an error</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Sent by:</font>
<td><font size=1 face="sans-serif">mpi3-ft-bounces@lists.mpi-forum.org</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>So the proposal makes no requirements about the state
of the distributed environment after an error. All it defines is a error
class to be returned by an MPI implementation once the MPI implementation
can no longer function correctly. This provides a necessary feedback mechanism
for the application to determine if and how the MPI implementation can
be used after an error occurs. It is the responsibility of the application
to avoid deadlocks and other such issues that can result from handling
and recovering from errors. If an application is designed to recover from
MPI_ERR_TAG that's great. If the MPI library allows for correct operation
after returning that error class, then even better. If the MPI library
cannot continue operation after that error then it can block subsequent
operations by returning MPI_ERR_CANNOT_CONTINUE.<br>
<br>
I disagree with your assessment that this will be difficult to implement/test
since a trivial implementation of this proposal is to set a global variable
when an error occurs to always return MPI_ERR_CANNOT_CONTINUE when the
application calls into the MPI library (it is a similar check as the 'is_mpi_initialized'
check that has to be there anyway). If an implementation wants to do more
(and it is definitely not required to do so) then it can define that in
it's documentation.<br>
<br>
If an application wants to try to use MPI after an error it must understand
that the error is local in nature (it cannot assume that every process
received an error). If it can figure out how to recover from it, and the
MPI implementation is able to function correctly afterward then we should
let them figure it out. This allows us to define the boundaries of correct
operation after an error. Before the application -could- keep using the
MPI library after an error, but it was entirely undefined and not-portable
what would happen. Now the application can portably attempt to use the
MPI library after an error and know that it can expect either normal functionality
(for those few implementations that do more than the minimum necessary)
or MPI_ERR_CANNOT_CONTINUE in which the library locks them out and they
then know to terminate normally.<br>
<br>
I hope this helps a bit, but maybe I am missing the core problem that you
are trying to get at.<br>
<br>
-- Josh<br>
<br>
On Sep 20, 2010, at 1:09 PM, Bronis R. de Supinski wrote:<br>
<br>
> <br>
> Dick:<br>
> <br>
> Re:<br>
>> I did not intend to ignore your use case.<br>
> <br>
> No problem.<br>
> <br>
>> I did mention that I have no worries about asking MPI implementations
<br>
>> to refrain from blocking future MPI calls after an error is detected.
<br>
>> That was an implicit recognition of your use case.<br>
> <br>
> OK, that helps.<br>
> <br>
>> The MPI standard already forbids having an MPI call on one thread
block <br>
>> progress on other threads.  I would interpret that to include
a case <br>
>> where a thread is blocked in a collective communication or a MPI_Recv
<br>
>> that will never be satisfied. That is, the blocked MPI call cannot
<br>
>> prevent other threads from using libmpi.  Requiring libmpi
to release <br>
>> any lock it took even when doing an error return would be logical
but <br>
>> may not be implied by what is currently written.<br>
> <br>
> The current text provides no such guarantee. Once anerror is<br>
> returned anywhere, all bets are off (at least that is how I<br>
> have read it; I would need to go back through the text to<br>
> find the exact words that cause my concern).<br>
> <br>
>> Communicators provide a sort of isolation that keeps stray crap
from <br>
>> failed operations from spilling over (such as eager sent message
for <br>
>> which the MPI_Recv failed).  If the tool uses its own threads
and <br>
>> private communicators, I agree it is reasonable to ask any libmpi
to <br>
>> avoid sabotaging that communication.<br>
> <br>
> That would be perfect from my perspective.<br>
> <br>
>> Where I get concerned is when we start talking about affirmative
<br>
>> requirements for distributed  MPI state after an error<br>
> <br>
> I don't think we can have those beyond "best effort".<br>
> The errors may indicate problems that make further<br>
> communication impossible -- perhaps because of the<br>
> erroneous action or just due to the state of the<br>
> network or other processes. I do think we can require<br>
> accurate return values and have an advice to implementers<br>
> that suggests best effort following errors. I believe<br>
> that would satisfy my requirements.<br>
> <br>
> Bronis<br>
> <br>
> <br>
> <br>
> <br>
>> <br>
>>                  Dick<br>
>> <br>
>> Dick Treumann  -  MPI Team<br>
>> IBM Systems & Technology Group<br>
>> Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
>> Tele (845) 433-7846         Fax (845) 433-8363<br>
>> <br>
>> <br>
>> <br>
>> From:   "Bronis R. de Supinski" <bronis@llnl.gov><br>
>> To:     "MPI 3.0 Fault Tolerance and Dynamic Process
Control working Group" <mpi3-ft@lists.mpi-forum.org><br>
>> Date:   09/20/2010 12:46 PM<br>
>> Subject:        Re: [Mpi3-ft] Defining the
state of MPI after an error<br>
>> Sent by:        mpi3-ft-bounces@lists.mpi-forum.org<br>
>> <br>
>> ________________________________<br>
>> <br>
>> <br>
>> <br>
>> <br>
>> Dick:<br>
>> <br>
>> You seem to be ignoring my use case. Specifically, I<br>
>> have tool threads that use MPI. Their use of MPI should<br>
>> be unaffected by all of the scenarios that you are raising.<br>
>> However, the standard provides no way for me to tell if<br>
>> they work correctly in these situations. I just have to<br>
>> cross my fingers and hope.<br>
>> <br>
>> FYI: Your implementation has long met this requirement<br>
>> (my hopes are not dashed with it). Others have begun to<br>
>> recently. In any event, I would like some way to tell...<br>
>> <br>
>> Further, it is useful in many other scenarios apply to know<br>
>> that the implementation intends to remain usable. I am not<br>
>> looking for a promise of correct execution; I am looking<br>
>> for a promise of best effort and accurate return codes.<br>
>> <br>
>> Bronis<br>
>> <br>
>> <br>
>> <br>
>> On Mon, 20 Sep 2010, Richard Treumann wrote:<br>
>> <br>
>>> <br>
>>> If there is any question about whether these calls are still
valid after an error with an error handler that returns (MPI_ERRORS_RETURN
or user handler)<br>
>>> <br>
>>> MPI_Abort,<br>
>>> MPI_Error_string<br>
>>> MPI_Error_class<br>
>>> <br>
>>> I assume it should be corrected as a trivial oversight in
the original text.<br>
>>> <br>
>>> I would regard the real issue as being the difficulty with
assuring the state of remote processes.<br>
>>> <br>
>>> There is huge difficulty in making any promise about how an
interaction between a process that has not taken an error and one that
has will behave.<br>
>>> <br>
>>> For example, if there were a loop of 100 MPI_Bcast calls and
on iteration 5, rank 3 uses a bad communicator, what is the proper state?
 Either a sequence number is mandated so the other ranks hang quickly
or a sequence number is prohibited so everybody keeps going until the "end"
when the missing MPI_Bcast becomes critical.  Of course, with no sequence
number, some tasks are stupidly using the iteration n-1 data for their
iteration n computation.<br>
>>> <br>
>>> <br>
>>> <br>
>>> <br>
>>> <br>
>>> <br>
>>> Dick Treumann  -  MPI Team<br>
>>> IBM Systems & Technology Group<br>
>>> Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY
12601<br>
>>> Tele (845) 433-7846         Fax (845)
433-8363<br>
>>> <br>
>> _______________________________________________<br>
>> mpi3-ft mailing list<br>
>> mpi3-ft@lists.mpi-forum.org<br>
>> </font></tt><a href="http://blockedlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
>> <br>
>> <br>
>> <br>
> _______________________________________________<br>
> mpi3-ft mailing list<br>
> mpi3-ft@lists.mpi-forum.org<br>
> </font></tt><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
> <br>
<br>
------------------------------------<br>
Joshua Hursey<br>
Postdoctoral Research Associate<br>
Oak Ridge National Laboratory<br>
</font></tt><a href=http://www.cs.indiana.edu/~jjhursey><tt><font size=2>http://www.cs.indiana.edu/~jjhursey</font></tt></a><tt><font size=2><br>
<br>
<br>
_______________________________________________<br>
mpi3-ft mailing list<br>
mpi3-ft@lists.mpi-forum.org<br>
</font></tt><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>