From owner-sc22wg5@open-std.org  Tue Nov 11 22:46:22 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 EF041C178D9; Tue, 11 Nov 2008 22:46:21 +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 EC933C178D6
	for <sc22wg5@open-std.org>; Tue, 11 Nov 2008 22:46:20 +0100 (CET)
X-Attachments: None
X-IronPort-AV: E=McAfee;i="5300,2777,5430"; a="30906476"
X-IronPort-AV: E=Sophos;i="4.33,586,1220252400"; 
   d="scan'208";a="30906476"
Received: from cyrus2.llnl.gov ([128.15.97.105])
  by nspiron-2.llnl.gov with ESMTP; 11 Nov 2008 13:46:18 -0800
From: Aleksandar Donev <donev1@llnl.gov>
Organization: LLNL
Subject: Re: (j3.2006) (SC22WG5.3659) [ukfortran] N1755: Request for new features from =?iso-8859-1?q?MPI=09Forum?=
Date: Tue, 11 Nov 2008 13:46:17 -0800
User-Agent: KMail/1.9.4
Cc: WG5 <sc22wg5@open-std.org>
References: <49137AD3.1070402@lrz.de> <20081111181417.B7A22C178D6@www2.open-std.org> <20081111192352.ED310C178D6@www2.open-std.org>
In-Reply-To: <20081111192352.ED310C178D6@www2.open-std.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
To: Undisclosed.Recipients: ;
Message-Id: <200811111346.18364.donev1@llnl.gov>
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

Nick,

> Consider code like the following:
>
>     INTEGER, ASYNCHRONOUS :: fred
>     fred = 0
>     SYNC MEMORY
>     Nothing that uses fred
>     SYNC MEMORY
>     ... = fred
>
> With your proposal, the compiler has to assume that fred may have changed.
> Currently, it does not.
Wouldn't adding a new attribute ASYNC_EXTERNAL or some such fix this? This is 
one of the options mentioned.

> Consider the restrictions on VOLATILE arguments (e.g. no VALUE and no
> INTENT(IN), and the proposal to require it to be set in all scopes or
> none). How many of those would you need to add to ASYNCHRONOUS in order to
> close loopholes opened by your proposal?
Most of those restrictions apply to *both* VOLATILE and ASYNCHRONOUS (see 
Clause 12). If they don't, it is probably an existing bug in the standard!

> This one is very simple, anyway.  As far as the program is concerned, MPI
> transfers are semantically just a specialised form of I/O.  Does anyone
> seriously dispute that?
I am not, obviously I proposed to extend the already existing mechanisms we 
have for async Fortran I/O to cover user-defined data transfers.

Best,
Aleks