<HTML>
<HEAD>
<TITLE>Re: [Mpi-22] MPI_INIT assertions</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>I think we are splitting hairs on wording here. In one case the user is saying “I don’t care about<BR>
the performance of cancel” and in the other “I promise not to call cancel”. Neither is changing the<BR>
semantics of MPI.<BR>
<BR>
Rich<BR>
<BR>
<BR>
On 5/15/08 5:44 PM, "Richard Treumann" <treumann@us.ibm.com> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Hi Rich <BR>
<BR>
The difference between a hint and an assertion is that an hint cannot change semantic in any way. An assertion will allow libmpi to relax a specific semantic guarantee. Lets take a simple case:<BR>
<BR>
The application wants to say it will not try to cancel any MPI_ISEND so it passes MPI_NO_SEND_CANCEL to MPI_INIT<BR>
<BR>
If MPI_INIT were passed MPI_NO_SEND_CANCEL as a <B>hint </B>and then the application went ahead and called MPI_CANCEL anyway, it would be fine for the MPI implementation to use a much slower MPI_CANCEL algorithm than if the hint had not been given. It would <B>not be OK</B> for the implementation to hang or raise an error or cancel the wrong message.<BR>
<BR>
If MPI_Init were passed MPI_NO_SEND_CANCEL as an<B> assertion </B>and then the application went ahead and called MPI_CANCEL anyway, it would be OK for the MPI implementation to raise an error for the MPI_CANCEL call.<BR>
<BR>
Every MPI Implementation must still be prepared to do MPI_CANCEL of an ISEND correctly if MPI_CANCEL is called by an application that <B>did not</B> provide the assertion. Adding assertion support in MPI 2.2 cannot break a correct MPI 2.1 application.<BR>
<BR>
The MPI_NO_SEND_CANCEL is only useful for cases where libmpi must devote extra memory, longer code paths or extra space in message headers across an entire run just to have the information it needs to do MPI_CANCEL correctly is somebody happens to call it. If a particular MPI implementation does not incur extra costs to be ready for a potential MPI_CANCEL then the implementation will ignore this assertion.<BR>
<BR>
Dick<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>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'>mpi-22-bounces@lists.mpi-forum.org wrote on 05/15/2008 01:33:02 PM:<BR>
<BR>
> Assertions should not change semantics – these are defined by the <BR>
> standard. Assertions<BR>
> may provide “help” to the implementation, what ever that means. I <BR>
> may be missing some thing,<BR>
> but I really don’t see a difference (aside from name) between <BR>
> assertions an hints – both are<BR>
> ways of the user conveying information to the library.<BR>
> <BR>
> Rich<BR>
> <BR>
</SPAN></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'>_______________________________________________<BR>
mpi-22 mailing list<BR>
mpi-22@lists.mpi-forum.org<BR>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</a><BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'><BR>
</SPAN></FONT></FONT>
</BODY>
</HTML>