<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="HTML Tidy for Windows (vers 25 March 2009), see www.w3.org">
<meta name="Generator" content="MS Exchange Server version 14.03.0123.002">
<title>[EXTERNAL] Re: [Mpi3-rma] request-based ops</title>
</head>
<body>
As an FYI, my problem with this proposal is two-fold:<br>
<br>
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).<br>
<br>
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.<br>
<br>
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...<br>
<br>
Brian<br>
<br>
<br>
<br>
Sent with Good (www.good.com)<br>
<br>
<br>
-----Original Message-----<br>
<b>From: </b>Pavan Balaji [<a href="mailto:balaji@mcs.anl.gov">balaji@mcs.anl.gov</a>]<br>
<b>Sent: </b>Friday, June 14, 2013 02:51 PM Mountain Standard Time<br>
<b>To: </b>mpi3-rma@lists.mpi-forum.org<br>
<b>Subject: </b>[EXTERNAL] Re: [Mpi3-rma] request-based ops<br>
<br>
<!-- Converted from text/plain format --><br>
<p><font size="2">On 06/14/2013 03:43 PM, Jim Dinan wrote:<br>
> Ahh, right, I had to miss that session at the Forum meeting.  If anyone<br>
> else is looking for them, these are the slides:<br>
><br>
> <a href="http://meetings.mpi-forum.org/secretary/2013/06/slides/2013-06-06-Nonblocking-Operations.pdf">
http://meetings.mpi-forum.org/secretary/2013/06/slides/2013-06-06-Nonblocking-Operations.pdf</a><br>
><br>
> I was indeed forgetting about remote versus local completion and polling<br>
> on the request.  It sounds like this would definitely fill a gap in the<br>
> RMA interface.<br>
<br>
FYI, this was not meant to be an RMA proposal, since it touches blocking<br>
function calls in many chapters (e.g., COMM_ICONNECT and COMM_IACCEPT).<br>
<br>
I think I/O operations have a similar ticket as well.<br>
<br>
All these tickets need to be combined into a single nonblocking<br>
operations ticket.<br>
<br>
  -- Pavan<br>
<br>
--<br>
Pavan Balaji<br>
<a href="http://www.mcs.anl.gov/~balaji">http://www.mcs.anl.gov/~balaji</a><br>
_______________________________________________<br>
mpi3-rma mailing list<br>
mpi3-rma@lists.mpi-forum.org<br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
</font></p>
</body>
</html>