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

Jim Dinan james.dinan at gmail.com
Sun Jun 16 10:02:25 CDT 2013


If the channel is unordered, a message after the iflush can increment the
counter, while one before the iflush has not yet completed.  So, the
counter is not enough to mark a particular point in time.

An implementation of iflush as flush should still be valid, right?  Just
check if the counters are equal in test/wait.  It won't be as fine grain as
what the user wants, but it should also have no impact on programs that
don't use iflush.

Although, the following program may never complete, so maybe the iflush as
flush implementation is not valid.

Iflush(...)
Do
   Test(req, &flag)
   If (!flag) Get(...)
While(!flag)

Jim.
On Jun 15, 2013 8:42 PM, "Pavan Balaji" <balaji at mcs.anl.gov> wrote:

> Hi Brian
>
> On 06/15/2013 11:24 AM, Barrett, Brian W wrote:
>
>> 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.
>>
>
> I think this model with a global counter will still work.  The IFLUSH
> request object will need to know what the counter needs to be to mark this
> request as complete.  So when there's a test/wait on this request, you
> compare this with the global counter.
>
>  -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> ______________________________**_________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi3-rma<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130616/bea8cb93/attachment-0001.html>


More information about the mpiwg-rma mailing list