But this can't be done in hardware easily so how did we ever let it into the RMA chapter? :-) Ah, now I see that I don't have to care about this because M**LOC only acts on special types and thus cannot be assured of atomicity w.r.t. any other ops that act on non-pair types. I am trying to get to the point where the default atomicity in RMA is something usable by SHMEM... Thanks, Jeff On Thu, Mar 13, 2014 at 2:25 PM, Jim Dinan <[email protected]> wrote:

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 <[email protected]> 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 [email protected] _______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

-- Jeff Hammond [email protected]