I think i have figured it out. Will post back if I have any further doubts. <br>Thanks,<br>Krishna Chaitanya K <br><br><div class="gmail_quote">On Sun, Mar 2, 2008 at 1:02 AM, Krishna Chaitanya &lt;<a href="mailto:kris.c1986@gmail.com">kris.c1986@gmail.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">&gt;Not sure I understand your question fully,<br></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Basically, I am trying to modify the MPICH library to invoke a callback when a message gets inserted into the unex queue and also monitor the unex queue&#39;s length. <br>
<div class="Ih2E3d">
<br>&gt;So, if the message from<br>
the other send arrives in the meanwhile, MPID_Progress_Wait will cause it to<br>
be received and placed in the unexpected queue.<br>&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;  <br></div>&nbsp; &nbsp; &nbsp; Well, This is what I have understood : <br>1. MPI_Irecv calls MPIDI_CH3U_Recvq_FDU_or_AEP. This scans through the unex queue. In my case, there isnt one, so it creates a new request and inserts it into the posted queue. <br>

2. MPI_Irecv returns.<br>3. MPI_Iwait calls MPIDI_CH3i_Progress_wait which calls MPIDI_CH3I_Progress_handle_sock_event in a loop. <br>4. If the event is MPIDU_SOCK_OP_READ and if the conn-&gt;state is connected, and MPIDI_CH3U_Recvq_FDP_or_AEU gets called. This function scans through the posted queue for a match. If a match is found, it gets dequeued. Else, it is placed into the unex queue. <br>

<br>OK...<br>&nbsp;&nbsp; A node can actually gather a new incoming message only when it is in the progress engine. The progress engine is invoked only by MPI_Wait. MPI_Wait gets called only after MPI_Irecv returns. (Am i right so far ? ) <br>

<br>&nbsp; From the traces that I have done so far, I have observed that a new message is not getting into the unex queue, as a matching MPI_Irecv has already been executed. ( Which has placed the recv request in the posted queue) . When MPIDI_CH3U_Recvq_FDP_or_AEU is called from the progress engine, a matching request in the posted queue is invariably found and the new message is not really &quot;unexepected&quot; from the receiver&#39;s standpoint. <br>

<br>&nbsp;This is what my code looks like : <br>&nbsp;sender side :&nbsp; <br>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style="color: rgb(51, 51, 255);">MPI_Isend (buffer, 1, MPI_INTEGER, 1, 1001, MPI_COMM_WORLD, &amp;req2[0]);</span><br style="color: rgb(51, 51, 255);">

<span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPI_Isend (buffer, 1, MPI_INTEGER, 1, 1002, MPI_COMM_WORLD, &amp;req2[1]);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; printf(&quot; [%d] MPI_Isend returns \n&quot;,rank);</span><br style="color: rgb(51, 51, 255);">

<span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPI_Wait( &amp;req2[0] , &amp;sts2[0]);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPI_Wait( &amp;req2[1], &amp;sts2[1]);</span><br>

<br>&nbsp; receiver side : <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style="color: rgb(51, 51, 255);">sleep(10);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPI_Irecv (buffer, 1, MPI_INTEGER, 0, 1001, MPI_COMM_WORLD, &amp;(req1[0]));</span><br style="color: rgb(51, 51, 255);">

<span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sleep(10);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPI_Irecv (buffer, 1, MPI_INTEGER, 1, 1002, MPI_COMM_WORLD, &amp;(req1[1]));</span><br style="color: rgb(51, 51, 255);">

<span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPI_Wait(&amp;req1[0], &amp;sts1[0]);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPI_Wait(&amp;req1[1], &amp;sts1[1]);</span><br style="color: rgb(51, 51, 255);">

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; I tried to have those sleep()&#39;s to make the reciever operate slower than the sender. &nbsp;&nbsp;  <br>&nbsp;&nbsp; Thanks for your time and please let me know if I am missing something . <br><font color="#888888"><br>
<br>Krishna Chaitanya,<br>
Final Year B-Tech,<br>National Institute of Technology,Karnataka.</font><div><div></div><div class="Wj3C7c"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br><br><div class="gmail_quote">On Fri, Feb 29, 2008 at 7:44 PM, Rajeev Thakur &lt;<a href="mailto:thakur@mcs.anl.gov" target="_blank">thakur@mcs.anl.gov</a>&gt; wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; I just started looking into the non-blocking calls today. I am<br>

&gt; not sure of whats happening in the call : MPIR_Grequest_progress_poke.<br>
&gt; What exactly is the difference between a generalized request and a<br>
&gt; native request?<br>
<br>
</div>A generalized request is something defined in MPI-2&#39;s chapter on external<br>
interfaces. It is a way for a new library to define its own nonblocking<br>
operations and use MPI_Request objects to test or wait on.<br>
MPIR_Grequest_progress_poke uses an extension to MPI-2 generalized requests,<br>
as explained in<br>
<a href="http://www-unix.mcs.anl.gov/%7Ethakur/papers/grequest-redesign.pdf" target="_blank">http://www-unix.mcs.anl.gov/~thakur/papers/grequest-redesign.pdf</a>. But you<br>
can just ignore generalized requests for now.<br>
<div><br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; I am also keen on knowing how an unexpected message is handled<br>
&gt; by MPICH2 and I have understood what happens in the function<br>
&gt; MPIDI_CH3U_Recvq_FDU_or_AEP(). &nbsp;So, I had two ranks(ranks 0 and 1)<br>
&gt; executing MPI_Isend() and one rank(rank 2) executing the two matching<br>
&gt; MPI_Irecv() calls, with the hope that the message that is &nbsp;arriving<br>
&gt; from rank 1 would be unexpected from rank 2&#39;s standpoint. &nbsp;But, as it<br>
&gt; turns out, MPI_Wait() actually calls MPID_Progress_Wait(). This is a<br>
&gt; blocking call and the MPI_Isend() that is being executed by rank1 is<br>
&gt; blocked until rank2 executes the corresponding MPI_Irecv().<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; My question is, how can I get an incoming message at rank 2 to<br>
&gt; get into the unexpected queue and wait there till the receiver scans<br>
&gt; through the &nbsp;queue until a match is found and proceeds to transfer of<br>
&gt; data?<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; To make this happen, MPID_Progress_Wait must never get called<br>
&gt; and so the MPI_Wait must constantly. Is that correct?<br>
<br>
</div>Not sure I understand your question fully, but MPID_Progress_wait will block<br>
until some (any) event occurs. That event need not be the event of interest,<br>
namely, the one for which the MPI_Wait was called. So, if the message from<br>
the other send arrives in the meanwhile, MPID_Progress_Wait will cause it to<br>
be received and placed in the unexpected queue.<br>
<font color="#888888"><br>
Rajeev<br>
<br>
</font></blockquote></div><br><br clear="all"><br></div></div>-- <br><div><div></div><div class="Wj3C7c">In the middle of difficulty, lies opportunity
</div></div></blockquote></div><br><br clear="all"><br>-- <br>In the middle of difficulty, lies opportunity