[mpich-discuss] Re: [MPICH] Problem setting up MPICH between a 32 bit INTEL and a 32 bit AMD machine

[Krishna Chaitanya]

>Not sure I understand your question fully,
        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.

>So, if the message from
the other send arrives in the meanwhile, MPID_Progress_Wait will cause it to
be received and placed in the unexpected queue.

      Well, This is what I have understood :
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.
2. MPI_Irecv returns.
3. MPI_Iwait calls MPIDI_CH3i_Progress_wait which calls
MPIDI_CH3I_Progress_handle_sock_event in a loop.
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.

OK...
   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 ? )

  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.

 This is what my code looks like :
 sender side :
                MPI_Isend (buffer, 1, MPI_INTEGER, 1, 1001, MPI_COMM_WORLD,
&req2[0]);
                MPI_Isend (buffer, 1, MPI_INTEGER, 1, 1002, MPI_COMM_WORLD,
&req2[1]);
                printf(" [%d] MPI_Isend returns \n",rank);
                MPI_Wait( &req2[0] , &sts2[0]);
                MPI_Wait( &req2[1], &sts2[1]);

  receiver side :
               sleep(10);
               MPI_Irecv (buffer, 1, MPI_INTEGER, 0, 1001, MPI_COMM_WORLD,
&(req1[0]));
                sleep(10);
                MPI_Irecv (buffer, 1, MPI_INTEGER, 1, 1002, MPI_COMM_WORLD,
&(req1[1]));
                MPI_Wait(&req1[0], &sts1[0]);
                MPI_Wait(&req1[1], &sts1[1]);

    I tried to have those sleep()'s to make the reciever operate slower than
the sender.
   Thanks for your time and please let me know if I am missing something .


Krishna Chaitanya,
Final Year B-Tech,
National Institute of Technology,Karnataka.


On Fri, Feb 29, 2008 at 7:44 PM, Rajeev Thakur <thakur at mcs.anl.gov> wrote:

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


-- 
In the middle of difficulty, lies opportunity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20080302/f6c90a48/attachment.htm>