From owner-sc22wg5@open-std.org  Thu Dec  4 05:50:36 2008
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 43E5DCA5FE7; Thu,  4 Dec 2008 05:50:36 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from nspiron-2.llnl.gov (nspiron-2.llnl.gov [128.115.41.82])
	by www2.open-std.org (Postfix) with ESMTP id 81BECC56CF8
	for <sc22wg5@open-std.org>; Thu,  4 Dec 2008 05:50:35 +0100 (CET)
X-Attachments: None
Received: from vpna-user-128-15-244-72.llnl.gov (HELO [128.15.244.72]) ([128.15.244.72])
  by nspiron-2.llnl.gov with ESMTP; 03 Dec 2008 20:50:35 -0800
Message-ID: <49376199.3070302@llnl.gov>
Date: Wed, 03 Dec 2008 20:50:33 -0800
From: Aleksandar Donev <donev1@llnl.gov>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.5
MIME-Version: 1.0
To: WG5 <sc22wg5@open-std.org>
Subject: Re: Nick's MPI non-blocking proposal
References: <200812031523.23143.donev1@llnl.gov>
In-Reply-To: <200812031523.23143.donev1@llnl.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

Hello,

I am going to go out of line and actually give a positive review of 
Nick's proposal :-) I like the basic design, which I have advocated as 
well (asynchronous attribute for non-blocking two-sided transfer, and 
volatile for one-sided target windows). It is similar to my own proposal 
except that it does not use SYNC MEMORY but proposes two new intrinsics 
(this sounds like a good idea).

> SET_PENDING (ID, INPUT, A1, [A2, ...])
> SET_PENDING shall be called on an affector before the mechanism
> external to Fortran initiates the asynchronous I/O.
OK from Fortran.

> If that is too horrible, and I think that it is, then the C interface
> would need to specify the number of arguments that make up the
> affector.
Can you please explain why it is needed to call this from C, and what 
that would mean in terms of implementation? I see how it tells the 
Fortran compiler that asynch I/O starts/ends so it knows when to flush 
buffers/registers/etc., but what would it mean to C??? An example would 
be great.

>  A Fortran processor need not do anything other
> than define ID to be a suitable value in SET_PENDING if it does
> not need that information.
I missed one thing: What is a "suitable value", i.e., are there 
constraints on the values (e.g., they have to be distinct from other 
pending states or what?).

Best,
Aleks