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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: Does MPI_Test fit your needs?

--Junchao Zhang

On Thu, Apr 2, 2015 at 7:16 PM, Lei Shi <[email protected]> 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 [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

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

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

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

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss