<html><body>
<p>If an application has unpredictable behavior then it should not make assertions. The author of an application that loads arbitrary helpers at run time (like the "new physics module") should know that he cannot safely make assertions that cover those helpers.  No application or helper can possibly "require an assertion".  Zero assertions is valid for any correct MPI program.<br>
<br>
I think almost all the value of assertions is lost if the MPI implementation must be prepared at all times to have any assertion revoked.<br>
<br>
<br>
 <br>
Dick Treumann  -  MPI Team/TCEM            <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846         Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi3-subsetting-bounces@lists.mpi-forum.org wrote on 06/20/2008 01:42:34 PM:<br>
<br>
> At 10:12 AM 6/20/2008, Richard Treumann wrote:<br>
</tt><br>
<tt>> Of course - <br>
> <br>
> An assertion is a statement that the application does not require <br>
> some MPI standard feature or semantic guarantee. It is not a <br>
> directive to the MPI implementation. The implementation is free to <br>
> provide that feature or guarantee even if the application says it is<br>
> not needed. <br>
> <br>
> The story is a bit different for a helper library because the <br>
> library is logically a more or less opaque part of the application. <br>
> If the caller of MPI_INIT_ASSERTED says the application does not <br>
> require something and then uses a library that does require that <br>
> feature or guarantee - the library must raise an error or adjust its<br>
> behavior to live within the assertion.</tt><br>
<tt>> <br>
> While I understand the intention, am a bit worried about the<br>
> implications. Imagine a long running application that loads<br>
> a new physics module after hours of computation and this new<br>
> module requires different assertions. If the only option it<br>
> has is to fail, a lot of progress in the main application will<br>
> get lost. The only alternative is for the application to never<br>
> state any assertion since it does not know which modules it<br>
> will load (often depends on the input deck) - and then the<br>
> whole exercise will be pointless anyway.<br>
> <br>
> Also, tools often need very specific MPI features and can't live<br>
> with many assertions (just taking from Rich's examples in the<br>
> other emails: there is often a need to use wildcards or complex <br>
> datatypes even if the application doesn't use it). Not being<br>
> able to change this would basically eliminate the ability to<br>
> use certain tools on certain applications (I realize that tools<br>
> that run from the beginning can intercept MPI_Init and turn<br>
> assertions off, but tools that attach can't).<br>
> <br>
> Hence, I think we need some way to change assertions at runtime<br>
> (at very specific points only and as global operations) despite <br>
> the extra complexity it will introduce.<br>
> <br>
> Martin<br>
> <br>
> <br>
> <br>
> <br>
> <br>
</tt><br>
<tt>> Dick Treumann - MPI Team/TCEM <br>
> IBM Systems & Technology Group<br>
> Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
> Tele (845) 433-7846 Fax (845) 433-8363<br>
> <br>
> <br>
> mpi3-subsetting-bounces@lists.mpi-forum.org wrote on 06/20/2008 12:58:03 PM:<br>
> <br>
> > Hi,<br>
> >  <br>
> > Ignoring an assertion should be perfectly legal.<br>
> >  <br>
> > Best regards.<br>
> >  <br>
> _______________________________________________<br>
> mpi3-subsetting mailing list<br>
> mpi3-subsetting@lists.mpi-forum.org<br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting</a> </tt><br>
<tt>> _______________________________________________________________________<br>
> Martin Schulz, schulzm@llnl.gov, <a href="http://people.llnl.gov/schulz6">http://people.llnl.gov/schulz6</a><br>
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA <br>
> _______________________________________________<br>
> mpi3-subsetting mailing list<br>
> mpi3-subsetting@lists.mpi-forum.org<br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting</a><br>
</tt></body></html>