From owner-sc22wg5@open-std.org Thu Dec 4 10:40:49 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id F20C1C178E6; Thu, 4 Dec 2008 10:40:48 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by www2.open-std.org (Postfix) with ESMTP id 42132C178E0 for ; Thu, 4 Dec 2008 10:40:46 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38155) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:nmm1) id 1L8AhR-0005L8-66 (Exim 4.70) for sc22wg5@open-std.org (return-path ); Thu, 04 Dec 2008 09:40:45 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1L8AhR-0005Yd-SF (Exim 4.67) for sc22wg5@open-std.org (return-path ); Thu, 04 Dec 2008 09:40:45 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 04 Dec 2008 09:40:45 +0000 Date: 04 Dec 2008 09:40:45 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.3732) Nick's MPI non-blocking proposal Message-ID: In-Reply-To: <20081204045036.63332C56CF8@www2.open-std.org> References: <200812031523.23143.donev1@llnl.gov> <20081204045036.63332C56CF8@www2.open-std.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Dec 4 2008, Aleksandar Donev wrote: > >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). Thank you. >> 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. It means nothing to C! The point of allowing it to be called from C is if the asynchronous I/O is written in C (e.g. MPI). It provides Fortran with exactly the same information that it would get if it passed an ASYNCHRONOUS variable to a subroutine that then performed asynchronous I/O on it. My guess is that few Fortran compilers would use the information, but it needs to be provided in case any do. >> 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?). Whatever the constraints are on a value returned via ID= in an asynchronous READ or WRITE! I tried chasing that up, and didn't find much. Yes, the wording probably needs clarifying. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679