>Not sure I understand your question fully,<br> 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's length. <br>
<br>>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> <br> 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->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> 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> 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 "unexepected" from the receiver's standpoint. <br>
<br> This is what my code looks like : <br> sender side : <br> <span style="color: rgb(51, 51, 255);">MPI_Isend (buffer, 1, MPI_INTEGER, 1, 1001, MPI_COMM_WORLD, &req2[0]);</span><br style="color: rgb(51, 51, 255);">
<span style="color: rgb(51, 51, 255);"> MPI_Isend (buffer, 1, MPI_INTEGER, 1, 1002, MPI_COMM_WORLD, &req2[1]);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);"> printf(" [%d] MPI_Isend returns \n",rank);</span><br style="color: rgb(51, 51, 255);">
<span style="color: rgb(51, 51, 255);"> MPI_Wait( &req2[0] , &sts2[0]);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);"> MPI_Wait( &req2[1], &sts2[1]);</span><br>
<br> receiver side : <br> <span style="color: rgb(51, 51, 255);">sleep(10);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);"> MPI_Irecv (buffer, 1, MPI_INTEGER, 0, 1001, MPI_COMM_WORLD, &(req1[0]));</span><br style="color: rgb(51, 51, 255);">
<span style="color: rgb(51, 51, 255);"> sleep(10);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);"> MPI_Irecv (buffer, 1, MPI_INTEGER, 1, 1002, MPI_COMM_WORLD, &(req1[1]));</span><br style="color: rgb(51, 51, 255);">
<span style="color: rgb(51, 51, 255);"> MPI_Wait(&req1[0], &sts1[0]);</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);"> MPI_Wait(&req1[1], &sts1[1]);</span><br style="color: rgb(51, 51, 255);">
<br> I tried to have those sleep()'s to make the reciever operate slower than the sender. <br> Thanks for your time and please let me know if I am missing something . <br><br><br>Krishna Chaitanya,<br>
Final Year B-Tech,<br>National Institute of Technology,Karnataka.<br> <br><br><div class="gmail_quote">On Fri, Feb 29, 2008 at 7:44 PM, Rajeev Thakur <<a href="mailto:thakur@mcs.anl.gov">thakur@mcs.anl.gov</a>> 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">> I just started looking into the non-blocking calls today. I am<br>
> not sure of whats happening in the call : MPIR_Grequest_progress_poke.<br>
> What exactly is the difference between a generalized request and a<br>
> native request?<br>
<br>
</div>A generalized request is something defined in MPI-2'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 class="Ih2E3d"><br>
> I am also keen on knowing how an unexpected message is handled<br>
> by MPICH2 and I have understood what happens in the function<br>
> MPIDI_CH3U_Recvq_FDU_or_AEP(). So, I had two ranks(ranks 0 and 1)<br>
> executing MPI_Isend() and one rank(rank 2) executing the two matching<br>
> MPI_Irecv() calls, with the hope that the message that is arriving<br>
> from rank 1 would be unexpected from rank 2's standpoint. But, as it<br>
> turns out, MPI_Wait() actually calls MPID_Progress_Wait(). This is a<br>
> blocking call and the MPI_Isend() that is being executed by rank1 is<br>
> blocked until rank2 executes the corresponding MPI_Irecv().<br>
> My question is, how can I get an incoming message at rank 2 to<br>
> get into the unexpected queue and wait there till the receiver scans<br>
> through the queue until a match is found and proceeds to transfer of<br>
> data?<br>
> To make this happen, MPID_Progress_Wait must never get called<br>
> 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>-- <br>In the middle of difficulty, lies opportunity