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

[Barrett, Brian W]

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...

Brian



Sent with Good (www.good.com)


-----Original Message-----
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:
>
> http://meetings.mpi-forum.org/secretary/2013/06/slides/2013-06-06-Nonblocking-Operations.pdf
>
> 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
operations ticket.

  -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130614/17d9ad2f/attachment.html>