Pavan,

In my case, I don't care the data is correct or not. I know it sounds crazy at first time, but there are some numerical schemes designed for this situation. 

I think according to Jeff's post http://blogs.cisco.com/performance/dont-leak-mpi_requests. If we don't call MPI_Wait or test, the request object will not be released even the data transfer completes. 

I will test your suggestion to call  MPI_Request_free to release it manually. 

BTW, attached is my test result, 
1. The orange one uses MPI_ISend/MPI_IRecv with MPI_Wait to make sure the data has been received successfully.  The WTime is linear with iterations, which is correct.

2. The blue one uses MPI_ISend and MPI_IRecv without calling MPI_Wait. There are some jumps in WTime. Does it due to some resource leaking? I will try to call MPI_Request_free to solve those jumps. 

3. The green one uses MPI_IBsend and MPI_IRecv (should I use MPI_Recv with MPI_IBsend) without calling MPI_Wait. It is even slower than the case 1 with MPI_Wait. 




On Fri, Apr 3, 2015 at 1:29 PM, Balaji, Pavan <balaji@anl.gov> wrote:

No, the request object will get released fine when the data transfer completes.  It is a correct program.  What I meant is that, since the application never knows when the request completes, the user application cannot use the data in any meaningful way, IMO.

  -- Pavan

> On Apr 3, 2015, at 12:13 PM, Lei Shi <lshi@ku.edu> wrote:
>
> Pavan,
>
> Thanks. You mean since I don't call MPI_Wait at all, the request object does not get a chance to be released by the MPI library? Right? I will give it a try. Thanks again!
>
>
> On Fri, Apr 3, 2015 at 10:12 AM, Balaji, Pavan <balaji@anl.gov> wrote:
>
> You can free the request with MPI_Request_free if you don't want to wait on it.  I have no idea how you'll write a correct program without waiting for receive completions at least, though.
>
>   -- Pavan
>
> > On Apr 2, 2015, at 11:44 PM, Lei Shi <lshi@ku.edu> wrote:
> >
> > Hi Junchao,
> >
> > Thanks for your reply. For my case, I don't want to check the data have been received or not. So I don't want to call MPI_Test or any function to verify it. But my problem is like if I ignore calling the MPI_Wait, just call Isend/Irev, my program freezes for several sec and then continues to run. My guess is probably I messed up the MPI library internal buffer by doing this.
> >
> >
> > On Thu, Apr 2, 2015 at 7:25 PM, Junchao Zhang <jczhang@mcs.anl.gov> wrote:
> > Does MPI_Test fit your needs?
> >
> > --Junchao Zhang
> >
> > On Thu, Apr 2, 2015 at 7:16 PM, Lei Shi <lshi@ku.edu> wrote:
> > I want to use non-blocking send/rev MPI_Isend/MPI_Irev to do communication. But in my case, I don't really care what kind of data I get or it is ready to use or not. So I don't want to waste my time to do any synchronization  by calling MPI_Wait or etc API.
> >
> > But when I avoid calling MPI_Wait, my program is freezed several secs after running some iterations (after multiple MPI_Isend/Irev callings), then continues. It takes even more time than the case with MPI_Wait.  So my question is how to do a "true" non-blocking communication without waiting for the data ready or not. Thanks.
> >
> >
> > _______________________________________________
> > discuss mailing list     discuss@mpich.org
> > To manage subscription options or unsubscribe:
> > https://lists.mpich.org/mailman/listinfo/discuss
> >
> >
> > _______________________________________________
> > discuss mailing list     discuss@mpich.org
> > To manage subscription options or unsubscribe:
> > https://lists.mpich.org/mailman/listinfo/discuss
> >
> > _______________________________________________
> > discuss mailing list     discuss@mpich.org
> > To manage subscription options or unsubscribe:
> > https://lists.mpich.org/mailman/listinfo/discuss
>
> --
> Pavan Balaji  ✉️
> http://www.mcs.anl.gov/~balaji
>
> _______________________________________________
> discuss mailing list     discuss@mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
>

--
Pavan Balaji  ✉️
http://www.mcs.anl.gov/~balaji