From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Apr 5 23:42:17 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 502BD35698B; Fri, 5 Apr 2013 23:42:13 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by www.open-std.org (Postfix) with ESMTP id 6F6D835698B for ; Fri, 5 Apr 2013 23:42:05 +0200 (CEST) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUV9FLLVJJFcwiYVwbKGEmQ6UEWIlYvJ2@postini.com; Fri, 05 Apr 2013 14:42:07 PDT Received: from fortran.us.cray.com (172.31.19.200) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.2.342.3; Fri, 5 Apr 2013 16:30:27 -0500 Message-ID: <515F42F8.9060203@cray.com> Date: Fri, 5 Apr 2013 16:32:40 -0500 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4969) AW: [ukfortran] AW: Thoughts on Reinhold's thoughts References: <20130331013557.06C46356DD4@www.open-std.org> <20130401124437.69138356A01@www.open-std.org> <20130401140345.39966356D69@www.open-std.org> <20130405202359.0F0CE356C98@www.open-std.org> <20130405205925.3CF0D356CCD@www.open-std.org> In-Reply-To: <20130405205925.3CF0D356CCD@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk On 4/5/13 3:59 PM, Bader, Reinhold wrote: > This would apply only to coarrays inherited from the parent team, not to > team-locally generated coarrays. And for the former, the effect is not really > worse than what exists now. Consider > > subroutine foo(a) > real :: a(:) > ... = a(:) > : > end subroutine > > and code invoking it thusly with 2 images: > > real :: a(100)[*] > > : ! initialize a > if (this_image() == 1) then > a(:)[1] = ... > else > call foo(a) > end if > > Of course this is invalid code - but writing code that violates the synchronization rules does not mean > that the memory model is not consistent. Some words may be needed to clarify that the synchronization > rules apply with respect to the parent team for parent-team-inherited coarrays, but I think this should be > no real problem. I'm a bit confused here. There is no concept of an image "inheriting" coarrays from the parent team. Coarrays belong to images, not teams. The image is the *same* image it was before, with the same set of data. The things that change with the new team are the image index, the number of images, co-subscript values, and the scope of collective operations. I assume you mean a coarray that was either statically declared or allocated before the change to the new team, whereas a coarray that was not allocated before but becomes allocated in the context of the new team is not "inherited". But for the existing coarrays, what is meant by the idea that "synchronization rules apply with respect to the parent team"? The image does not have access to the images outside its team, and the SYNC operations do not involve any images outside the team. And, once you are down in a call stack, there would be no way to determine whether a particular coarray was in the "inherited" camp. This scheme of distinguishing coarrays and of adding SYNC methods outside the team are a significant departure from the basic design requirements for the current TEAM model. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101