[mpiwg-rma] {MAX,MIN}LOC in RMA

[Jim Dinan]

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.

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.

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.

 ~Jim.


On Thu, Mar 13, 2014 at 3:05 PM, Jeff Hammond <jeff.science at gmail.com>wrote:

> What is the expected behavior of {MAX,MIN}LOC in RMA?  I have a hard
> time seeing what the use would be.  Does anyone want to use MAXLOC to
> find the MAX of two numbers and write in the window the rank (chosen
> from the set of the initiator and the target) of the pair member that
> is larger?  It's not like one can use this to implement a one-sided
> reduction since any time the value in the window is larger, the
> information about the original LOC will be lost.
>
> Can we remove these operations from the set of accumulate operations?
>
> Thanks,
>
> Jeff
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20140313/bcb0e36e/attachment-0001.html>