[Mpi3-rma] [EXTERNAL] Re: request-based ops
james.dinan at gmail.com
Mon Jun 17 08:52:32 CDT 2013
It seems like there are two possible semantics for which operations are
complete by a call to MPI_Win_iflush:
(1) Completes all operations issued by the origin process on the given
window before MPI_Win_iflush was called.
(2) Completes all operations issued by the origin process on the given
window before MPI_Win_iflush completed.
So far, we've just been looking at #1, but I think that #2 is worth
considering. Option #2 allows an implementation that just checks if the
counters are equal. This avoids the issue where #1 can't be implemented in
terms of #2, because issuing an unbounded number of operations while
testing on the iflush request can cause the iflush to not complete
Option #2 does not directly provide the functionality that Jeff was looking
for, but this could be implemented using two windows. Issue a bunch of
operations on win1 and iflush on win2, when win2 has been flushed, switch
to issuing operations on win2 and iflushing win1.
On Mon, Jun 17, 2013 at 7:38 AM, Jim Dinan <james.dinan at gmail.com> wrote:
> Sorry, I should have been more specific. An implementation of iflush that
> waits for the completion of all messages should be valid. Such an
> implementation would compare counters and return true if they are the
> same. This implementation could have the issue I mentioned in the previous
> message, where the user continuously issuing operations can prevent iflush
> from completing.
> On Jun 16, 2013 10:13 AM, "Pavan Balaji" <balaji at mcs.anl.gov> wrote:
>> On 06/16/2013 10:02 AM, Jim Dinan wrote:
>>> 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.
>> Ah, good point.
>> An implementation of iflush as flush should still be valid, right? Just
>> No. You cannot do this if the user only uses TEST.
>> while (MPI_TEST(req) is not done);
>> -- Pavan
>> Pavan Balaji
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mpiwg-rma