From owner-sc22wg5@open-std.org Wed Jan 21 19:45:39 2009 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 8605CC178E0; Wed, 21 Jan 2009 19:45:39 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by www2.open-std.org (Postfix) with ESMTP id 43194C178D9 for ; Wed, 21 Jan 2009 19:45:37 +0100 (CET) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id n0LIjTLn019816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jan 2009 12:45:29 -0600 (CST) Received: from CFEXFE01.us.cray.com (cfexfe01.us.cray.com [172.30.74.93]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n0LIjS5e013414; Wed, 21 Jan 2009 12:45:28 -0600 Received: from mh-dhcp-172-31-16-180.us.cray.com ([172.31.16.180]) by CFEXFE01.us.cray.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 12:45:28 -0600 Message-ID: <49776DF7.1040900@cray.com> Date: Wed, 21 Jan 2009 12:48:23 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: MPI-3 Fortran working group Cc: WG5 Subject: Re: [MPI3 Fortran] MPI non-blocking transfers References: <49775A9D.3080102@cray.com> <200901211012.44002.donev1@llnl.gov> In-Reply-To: <200901211012.44002.donev1@llnl.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2009 18:45:28.0385 (UTC) FILETIME=[6DF81310:01C97BF8] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Aleksandar Donev wrote: > Hi Bill, > > >> Having the buffer automatically acquire this new attribute is >> necessary if we want to avoid requiring changes to existing codes. >> > This is raising red flags for me. Existing codes are *buggy*, and trying > to somehow make them conforming and well-behaved seems doomed to me. > Well, that's a point for discussion. Is it a goal to avoid requiring user source code changes? How important is this issue? This is something for MPI folks to decide. (This is a pretty basic question that probably should have been in the original list.) > >>> 2) Most people seem to agree that a data attribute is essential, >>> and a purely procedure-based solution will not work. >>> >>> Do you agree with this and, if not, why not? >>> >> The question hints at a common confusion. >> > Please answer the actual question. > I would have if the question were well-formed. It was not. I was just trying to explain the situation as clearly as possible. I'm looking at this from a vendor perspective. There are two issues that have separate solutions. Failing to understand this resulted in some bandwidth-wasting email recently, and I'm trying to head off more of the same. > >> Various solutions to >> this problem have been discussed, most centering on an attribute for >> dummy arguments >> > If so, your answer to question 2 is yes? > > >> or coding versions of the MPI routines that accept >> pass-by-descriptor rather than >> pass-by-address for the buffer argument. >> > Answer to question 2 is no---something new is proposed. Are you > proposing something new or do you prefer an ASYNCH_EXTERNAL attribute? > I'm open to either approach. This is something the MPI folks need to decide. Are they willing to have a completely different library interface for Fortran? > Or maybe you prefer not to do anything at all (i.e., ignore the issue). > Considering that people have been using MPI with considerable success for a very long time, that is one option. However, the discussion presupposes that facilities to reduce possible user problems are desired, so either you accept the premise or drop out of the discussion. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120