[Mpi3-subsetting] MPI subsetting: charting the way forward atatelecon next week?
Richard Treumann
treumann at [hidden]
Fri Jun 20 13:11:02 CDT 2008
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.
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.
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
mpi3-subsetting-bounces_at_[hidden] wrote on 06/20/2008 01:42:34
PM:
> At 10:12 AM 6/20/2008, Richard Treumann wrote:
> Of course -
>
> An assertion is a statement that the application does not require
> some MPI standard feature or semantic guarantee. It is not a
> directive to the MPI implementation. The implementation is free to
> provide that feature or guarantee even if the application says it is
> not needed.
>
> The story is a bit different for a helper library because the
> library is logically a more or less opaque part of the application.
> If the caller of MPI_INIT_ASSERTED says the application does not
> require something and then uses a library that does require that
> feature or guarantee - the library must raise an error or adjust its
> behavior to live within the assertion.
>
> While I understand the intention, am a bit worried about the
> implications. Imagine a long running application that loads
> a new physics module after hours of computation and this new
> module requires different assertions. If the only option it
> has is to fail, a lot of progress in the main application will
> get lost. The only alternative is for the application to never
> state any assertion since it does not know which modules it
> will load (often depends on the input deck) - and then the
> whole exercise will be pointless anyway.
>
> Also, tools often need very specific MPI features and can't live
> with many assertions (just taking from Rich's examples in the
> other emails: there is often a need to use wildcards or complex
> datatypes even if the application doesn't use it). Not being
> able to change this would basically eliminate the ability to
> use certain tools on certain applications (I realize that tools
> that run from the beginning can intercept MPI_Init and turn
> assertions off, but tools that attach can't).
>
> Hence, I think we need some way to change assertions at runtime
> (at very specific points only and as global operations) despite
> the extra complexity it will introduce.
>
> Martin
>
>
>
>
>
> Dick Treumann - MPI Team/TCEM
> IBM Systems & Technology Group
> Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
> Tele (845) 433-7846 Fax (845) 433-8363
>
>
> mpi3-subsetting-bounces_at_[hidden] wrote on 06/20/2008 12:58:03
PM:
>
> > Hi,
> >
> > Ignoring an assertion should be perfectly legal.
> >
> > Best regards.
> >
> _______________________________________________
> mpi3-subsetting mailing list
> mpi3-subsetting_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting
> _______________________________________________________________________
> Martin Schulz, schulzm_at_[hidden], http://people.llnl.gov/schulz6
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> _______________________________________________
> mpi3-subsetting mailing list
> mpi3-subsetting_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi3-subsetting/attachments/20080620/5fbf02a9/attachment.html>
More information about the Mpi3-subsetting
mailing list