From owner-sc22wg5@open-std.org Fri Jun 26 01:52:37 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 61BC8C76BCE; Fri, 26 Jun 2009 01:52:37 +0200 (CET DST) 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 4B279C76BC8 for ; Fri, 26 Jun 2009 01:52:10 +0200 (CET DST) 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 n5PNq8Qq011588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jun 2009 18:52:08 -0500 (CDT) Received: from CFEXFE01.us.cray.com (CFEXFE01.americas.cray.com [172.30.74.93]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n5PNq6Yc016961; Thu, 25 Jun 2009 18:52:06 -0500 Received: from bill-longs-macbook-pro.local ([192.168.239.26]) by CFEXFE01.us.cray.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 18:52:05 -0500 Message-ID: <4A440E30.3060304@cray.com> Date: Thu, 25 Jun 2009 18:54:24 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: fortran standards email list for J3 Cc: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4044) [ukfortran] LOCK/UNLOCK question References: <4A38A3BB.9090208@nag-j.co.jp><4A38B917.8080202@llnl.gov> <4A391682.8060208@cray.com> <061720091627.18164.4A39196C000C05A4000046F422230703729B0A02D29B9B0EBF02019C050C079D0B020A08D2050C070B@att.net> <4A3930E3.8070505@cray.com> <061720091851.25112.4A393B4100015BA20000621822228869349B0A02D29B9B0EBF02019C050C079D0B020A08D2050C070B@att.net> <4A397E50.9010406@nag-j.co.jp> <4A3F9897.8010103@llnl.gov> <4A3FA25D.1050507@cray.com> <4A3FF921.9070703@llnl.gov> <20090622221248.1FEF4C178E5@www2.open-std.org> <20090623084602.88A3EC178E5@www2.open-std.org> <20090624020300.8EE77C178E5@www2.open-std.org> <20090625033421.31AAEC3BB09@www2.open-std.org> <20090625051920.8B235C3BB09@www2.open-std.org> <20090625094501.CB3A0C4596C@www2.open-std.org> <20090625131644.E257CC4596C@www2.open-std.org> <20090625142825.739B8C76BBF@www2.open-std.org> <20090625153554.533C4C76BBF@www2.open-std.org> <20090625173159.77EC8C76BBF@www2.open-std.o! rg> In-Reply-To: <20090625173159.77EC8C76BBF@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2009 23:52:06.0007 (UTC) FILETIME=[F1D5A870:01C9F5EF] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk N.M. Maclaren wrote: > On Jun 25 2009, Bill Long wrote: >>> What version of the manual WAS it first documented in? >> Our current documentation policy is that the manuals mention only >> differences between our implementation and the standard. Since 6.0 in >> 2007, we've used Fortran 2003 as the base standard for the document. >> Since VOLATILE is part of the standard, it is not mentioned in the >> documentation. Ironically, when Fortran 2008 is published and we switch >> to that as the base, we will need to start documenting that off-image >> references to VOLATILE coarrays are exempted from the segment ordering >> rules as an extension. > > Yes, I know that. > > The only relevant wording for VOLATILE in the Fortran 2003 standard is > in 5.1.2.16: > > The VOLATILE attribute specifies that an object may be referenced, > defined, or become undefined, by means not specified by the program. > > NOTE 5.21 > The Fortran processor should use the most recent definition of a > volatile object when a value is required. Likewise, it should make > the most recent Fortran definition available. It is the programmer's > responsibility to manage the interactions with the non-Fortran > processes. > > It requires a leap of faith to assume that it will have inter-image > atomicicity (let alone synchronicity) properties. The manual is specific to a particular combination of compiler and supported hardware. For that hardware, there is no atomicity problem. (Besides, the same atomicity would affect other sorts of volatile memory operations - not just those related to coarrays.) And, anyway, the > WHOLE support for multiple images was a Cray extension, and so was > necessarily outside the standard! Yep. There is a whole section of the manual devoted to coarrays. Any experienced programmer will > look in the processor-dependent section for what semantics can be > assumed for VOLATILE coarrays - and there wasn't any - so almost all > experienced programmers would avoid them like the plague. The extension of volatile to coarrays was so completely obvious and trivial for this hardware that it did not seem necessary to include documentation. > > Sorry, no, that does NOT count as providing enough documentation to > claim that there is significant experience by ordinary users. Since when do ordinary users actually read the documentation? :) In my experience, they tend to just try what they think should work, and read the docs only if the result is failure. In this case, things work the way one would naively expect. > > When I first came to specify it in a procurement, I had to write my own > benchmarks because there were NO open source OpenMP programs around. > There are now a few, but its acceptance is still very poor. It is still > very much second to MPI, even on shared-memory systems. > The benchmarks I referred to are actual customer production codes. OpenMP often occurs in them. MPI occurs in almost every benchmark, including the ones that use OpenMP. So, yes, MPI is solidly in first place, at least for now. 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