<div class="gmail_quote">You might also consider MPI one-sided operations.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Jan 9, 2012 at 11:37, Jie Chen <span dir="ltr"><<a href="mailto:jiechen@mcs.anl.gov">jiechen@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"><div id=":3ge">Thank you very much for your kind reply. Let me describe my scenario. In my application each process needs data from every other processes and performs calculations. So a natural work flow, for process p0, is requests data from p1, does calculation; then requests data from p2, does calculation; so on and so forth. Even though the data are evenly distributed among processes, the work loads for each data are different. So other processes don't know when p0 requests data. Thus, a natural design is to let every process have 2 threads, while one thread is doing the normal calculations, the other is responsible for probing requests and sending/receiving data.<br>
<br>
What concerns me, is the efficacy of this design. Since probing costs CPU cycles, and since after one process sends the data request, and it has to wait the other process to receive the request and to send the data, there might be a lot overhead introduced in addition to the normal calculations. The MPI standard only defines what probing does, but it does not define how probing is implemented. So I guess it would be hard to estimate in advance how large the overhead is.<br>
<br>
On the other hand, knowing the overhead is beneficial, since I am at the stage of algorithmic design but not implementation. If I know that probing is problematic (which perhaps not), I would try to redo the algorithmic design and not allow things like "a process does not know when other processes request data from it" happen.</div>
</blockquote></div><br>