[Mpi3-rma] [EXTERNAL] Re: request-based ops
balaji at mcs.anl.gov
Fri Jun 14 18:06:55 CDT 2013
That's a fair point and I agree with it. We should not add overhead to existing functionality to support this. I guess the thought here is that for implementations that support fully asynchronous RMA communication, test or wait can essentially do the flush, with the caveat that test cannot block if someone else is holding the lock.
"Barrett, Brian W" <bwbarre at sandia.gov> wrote:
As an FYI, my problem with this proposal is two-fold:
First, we need to deal with the fact that many of the calls are local today, meaning we need to fix some definitions, which is a big change (iflush/flush shouldn't have the same semantics).
Second, the semantics of iflush (and friends) need lots of care. For example, allowing a communication event between iflush and wait would greatly hinder my implementation's performance when not using iflush.
I understand the desire and like many of the non-blocking, but there are many places that we should balance non-blocking variants vs. performance loss...
Sent with Good (www.good.com)
From: Pavan Balaji [balaji at mcs.anl.gov<mailto:balaji at mcs.anl.gov>]
Sent: Friday, June 14, 2013 02:51 PM Mountain Standard Time
To: mpi3-rma at lists.mpi-forum.org
Subject: [EXTERNAL] Re: [Mpi3-rma] request-based ops
On 06/14/2013 03:43 PM, Jim Dinan wrote:
> Ahh, right, I had to miss that session at the Forum meeting. If anyone
> else is looking for them, these are the slides:
> I was indeed forgetting about remote versus local completion and polling
> on the request. It sounds like this would definitely fill a gap in the
> RMA interface.
FYI, this was not meant to be an RMA proposal, since it touches blocking
function calls in many chapters (e.g., COMM_ICONNECT and COMM_IACCEPT).
I think I/O operations have a similar ticket as well.
All these tickets need to be combined into a single nonblocking
mpi3-rma mailing list
mpi3-rma at lists.mpi-forum.org
More information about the mpiwg-rma