<div dir="ltr">FYI, we added a test case for MPI_Accumulate with MIN/MAX_LOC to the MPICH test suite: <a href="http://git.mpich.org/mpich.git/commit/a80bf84aecfc6c6152474623d418b2a3cb71fd53">http://git.mpich.org/mpich.git/commit/a80bf84aecfc6c6152474623d418b2a3cb71fd53</a><div>
<br></div><div>Also, the mutex idea I had didn't pan out because of the LOC operators always chose the least loc when the values are equal. Can't think of a way to make this work..</div><div><br></div><div> ~Jim.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 3:25 PM, Jim Dinan <span dir="ltr"><<a href="mailto:james.dinan@gmail.com" target="_blank">james.dinan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">MAX/MIN_LOC operations have an (albeit odd) atomic compare and replace semantic. They operate on a pair type that has <value, location> components. The user provides the data for both value and location. The min/max comparison (i.e. less-than/greater-than) is done on the value. If the comparison is true, then the remote <value, location> is atomically replaced with the supplied data.<div>
<br></div><div>These operations can be useful for one-sided reductions. I think PetSC uses them for this. In MPI-2 (there are, of course better ways in MPI-3) you can also use these operations to implement a spinlock. The value is a boolean indicating if the mutex is taken and the location is the rank that hold the mutex. The mutex initially contains the unlocked value <0, MPI_PROC_NULL>. You do a MAX_LOC accumulate of <1, me> to try to claim the mutex then do a get to see if you succeeded (exclusive epochs because of mixing accumulates and gets and the same op restriction). To unlock, you write the unlocked value back to the mutex.</div>
<div><br></div><div>I have a test case that implements this, that's been queued up for a while waiting to go out to MPICH. Should be able to push it out soon.</div><span class="HOEnZb"><font color="#888888"><div><br>
</div><div> ~Jim.</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 3:05 PM, Jeff Hammond <span dir="ltr"><<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What is the expected behavior of {MAX,MIN}LOC in RMA? I have a hard<br>
time seeing what the use would be. Does anyone want to use MAXLOC to<br>
find the MAX of two numbers and write in the window the rank (chosen<br>
from the set of the initiator and the target) of the pair member that<br>
is larger? It's not like one can use this to implement a one-sided<br>
reduction since any time the value in the window is larger, the<br>
information about the original LOC will be lost.<br>
<br>
Can we remove these operations from the set of accumulate operations?<br>
<br>
Thanks,<br>
<br>
Jeff<br>
<span><font color="#888888"><br>
--<br>
Jeff Hammond<br>
<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br>
_______________________________________________<br>
mpiwg-rma mailing list<br>
<a href="mailto:mpiwg-rma@lists.mpi-forum.org" target="_blank">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>