[Mpi3-rma] [EXTERNAL] Re: request-based ops

Jeff Hammond jhammond at alcf.anl.gov
Sat Jun 15 12:42:18 CDT 2013

Related to this, I was wondering about the semantics of IWIN_FLUSH
when ordering was disabled for a window (i.e. accumulate_ordering="").

If I do the following, can I make any assumptions about the ordering
of the two accumulates?

MPI_Win win_with_unordered_accumulates;
MPI_Request req1, req2;

The Waitall is not required to act on the requests in order, right?
Thus is req2 is completed first, then it flushes both Accumulates
simultaneously, hence does not ordering them.  The completion of req1
is then trivial and have no effect on ordering Accumulate 1 before
Accumulate 2.



On Sat, Jun 15, 2013 at 11:24 AM, Barrett, Brian W <bwbarre at sandia.gov> wrote:
> On 6/15/13 10:47 AM, "Jim Dinan" <james.dinan at gmail.com> wrote:
> Can you elaborate on the source of performance loss from operations between
> Iflush and its completion?
> With the current semantics of flush, a valid implementation is a counter of
> number of operations started, another of operations completed, wait until
> they're equal.  On an unordered channel (and acks are usually on an
> unordered channel), this mode won't work and you either have to have
> multiple counters or start tracking events in some per-event way, neither of
> which are going to be as performant.
> Brian
> --
>   Brian W. Barrett
>   Scalable System Software Group
>   Sandia National Laboratories
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
ALCF docs: http://www.alcf.anl.gov/user-guides

More information about the mpiwg-rma mailing list