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

[Jeff Hammond]

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 <james.dinan at gmail.com> 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 <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
>
>
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma



-- 
Jeff Hammond
jeff.science at gmail.com