Thank you Ashley -

This is exactly the distinction between assertions and hints and the reason this narrow proposal advocates assertions and does not advocate hints.

An MPI_NO_SEND_CANCEL hint still requires the MPI implementation to invest whatever it takes, across the entire application life to do MPI_CANCEL correctly.

An MPI_NO_SEND_CANCEL assertion allows the MPI implementation to forgo those costs and just refuse to try to MPI_CANCEL if the application has an MPI_CANCEL call.

The assertion does relax a semantic guarentee (I say relax rather than change because "change" has broader implications but an assertion does change semantics in a narrow and well defined way). An MPI Implementation that is prepared to do MPI_CANCEL correctly has a different semantic than one that will issue an error message if MPI_CANCEL is called.

As a footnote -
MPI 2 defined some hints and MPI 3 may define more hints. That is OK. There are cases where a hint will allow an MPI implementation to give better performance without changing its semantic. In a situation where a hint is enough, the MPI standard should avoid defining an assertion.

Dick

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


mpi-22-bounces@lists.mpi-forum.org wrote on 05/15/2008 05:59:51 PM:

<snip>
>
> To me I see little benefit in offering MPI_NO_SEND_CANCEL as a hint, all
> that does is say to the library that a cancel is unlikely to happen and
> we all know that anyway.  As a cancel is still possible I see no
> opportunity for optimisation of any kind making itself possible, all the
> extra space in headers and longer code paths would still be needed
> anyway.
>
> As an assertion it would offer some scope for library writers to make
> simplifications leading to better performance, as a hint I can't see how
> it would change anything.
>
> Ashley,
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22@lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22