<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr">Yep, that did it, setting the <span style="font-family:arial,sans-serif;font-size:13px">MPICH_ASYNC_PROGRESS env var  to 1 fixed the issue, thanks!</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">So, why does that fix the issue? What is that env var causing internally in mpich to fix this scenario if you don't mind me asking.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Thanks,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Neil</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 22, 2014 at 5:29 PM, Rajeev Thakur <span dir="ltr"><<a href="mailto:thakur@mcs.anl.gov" target="_blank">thakur@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For this to work you need to enable asynchronous progress in MPICH at least on the target side. You can do that by setting the environment variable MPICH_ASYNC_PROGRESS to 1 before running mpiexec.<br>
<br>
Rajeev<br>
<br>
On Sep 22, 2014, at 4:53 PM, Neil Spruit <<a href="mailto:nrspruit@gmail.com">nrspruit@gmail.com</a>><br>
<div class="HOEnZb"><div class="h5"> wrote:<br>
<br>
> Hello,<br>
><br>
><br>
> I have been experimenting with mpich’s implementation of one-sided communication with no remote synchronization that was introduced in the mpi3.0 spec and I have run into a hang issue during connect/accept MPI scenarios.<br>
><br>
><br>
><br>
> Here is the situation,  I have two applications that connect to each other after they have been launched separately with mpiexec on two different hosts.<br>
><br>
><br>
> After connecting, both hosts allocate memory and run MPI_Win_Create as the following:<br>
><br>
> Host1_program:<br>
><br>
>    void* buffer = mmap(0, buf_length, PROT_READ | PROT_WRITE, MAP_SHARED|MAP_POPULATE|MAP_ANON, -1, 0);<br>
><br>
>     MPI_Intercomm_merge(connected_comm, 1, &comm);<br>
><br>
>     MPI_Comm_rank(comm, &myrank);<br>
><br>
>     MPI_Win_create(NULL, 0, 1, MPI_INFO_NULL, comm, &win);<br>
><br>
> Host2_program:<br>
><br>
>    void* buffer = mmap(0, buf_length, PROT_READ | PROT_WRITE, MAP_SHARED|MAP_POPULATE|MAP_ANON, -1, 0);<br>
><br>
>     MPI_Intercomm_merge(connected_comm, 1, &comm);<br>
><br>
>     MPI_Comm_rank(comm, &myrank);<br>
><br>
>     MPI_Win_create(buffer, buf_length, 1, MPI_INFO_NULL, comm, &win);<br>
><br>
><br>
><br>
> Once the MPI_Window has been created I execute the following on host1:<br>
><br>
>  Host1_program(continued):<br>
><br>
>        err = MPI_Win_lock(MPI_LOCK_SHARED, target_rank, 0, win);<br>
><br>
>         if(err != MPI_SUCCESS)<br>
><br>
>         {<br>
><br>
>             return 1;<br>
><br>
>         }<br>
><br>
>         err = MPI_Put(buffer, buf_length, MPI_BYTE, target_rank, 0, buf_length, MPI_BYTE, win);<br>
><br>
>         if(err != MPI_SUCCESS)<br>
><br>
>         {<br>
><br>
>             return 1;<br>
><br>
>         }<br>
><br>
>         err = MPI_Win_flush(target_rank, win);<br>
><br>
>         if(err != MPI_SUCCESS)<br>
><br>
>         {<br>
><br>
>             return 1;<br>
><br>
>         }<br>
><br>
>         err = MPI_Win_unlock(target_rank, win);<br>
><br>
>         if(err != MPI_SUCCESS)<br>
><br>
>         {<br>
><br>
>             return 1;<br>
><br>
>         }<br>
><br>
> While this is running, host2’s program is simply sleeping in a getchar().<br>
><br>
><br>
> This should run and complete, however, if the other host has not called another mpi function such as MPI_Recv and instead is in a sleep, getchar(), etc. the MPI_Win_flush above will simply hang.<br>
><br>
><br>
> Why is the one-sided operation hanging until another MPI operation is called on the target host? My understanding is that utilizing MPI_Win_Flush does not require any action by the target host to complete the operation.<br>
><br>
><br>
> This is a stack trace of where the flush gets stuck:<br>
><br>
> #0  0x0000003b456dea28 in poll () from /lib64/libc.so.6<br>
><br>
> #1  0x00007fe1c08004ee in MPID_nem_tcp_connpoll ()<br>
><br>
>    from /usr/local/lib/libmpich.so.12<br>
><br>
> #2  0x00007fe1c07efab7 in MPIDI_CH3I_Progress ()<br>
><br>
>    from /usr/local/lib/libmpich.so.12<br>
><br>
> #3  0x00007fe1c07d35ff in MPIDI_CH3I_Wait_for_lock_granted ()<br>
><br>
>    from /usr/local/lib/libmpich.so.12<br>
><br>
> #4  0x00007fe1c07d88bf in MPIDI_Win_flush () from /usr/local/lib/libmpich.so.12<br>
><br>
> #5  0x00007fe1c08c1b46 in PMPI_Win_flush () from /usr/local/lib/libmpich.so.12<br>
><br>
> #6  0x000000000040115c in main ()<br>
><br>
><br>
> According to this it seems that somehow the remote host is holding something after MPI_Win_Create that in my scenario gets unlocked if I call MPI_Recv on the connected_comm from above after the MPI_Win_Create.<br>
><br>
><br>
> Thank you for your time and I look forward to your reply.<br>
><br>
><br>
> Respectfully,<br>
><br>
> Neil Spruit<br>
><br>
><br>
><br>
> P.S. MPICH version info<br>
><br>
>     Version:                                 3.1<br>
><br>
>     Release Date:                        Thu Feb 20 11:41:13 CST 2014<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
> To manage subscription options or unsubscribe:<br>
> <a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
<br>
_______________________________________________<br>
discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
</div></div></blockquote></div><br></div>