From owner-sc22wg5@open-std.org Fri Nov 7 22:29:25 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 20C6DCA5FE8; Fri, 7 Nov 2008 22:29:25 +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 5C41FCA343A for ; Fri, 7 Nov 2008 22:29:23 +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 mA7LTM4X018897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Nov 2008 15:29:22 -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 mA7LTK23007651 for ; Fri, 7 Nov 2008 15:29:21 -0600 Received: from mh-dhcp-172-31-16-226.us.cray.com ([172.31.16.226]) by CFEXFE01.us.cray.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 15:29:20 -0600 Message-ID: <4914B397.4010603@cray.com> Date: Fri, 07 Nov 2008 15:31:03 -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: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.3648) [ukfortran] A comment on John Wallin's comments on Nick MacLaren's comments References: <20081105225653.DCEA7CA3428@www2.open-std.org> <20081106232341.ABD83CA343A@www2.open-std.org> <20081106233908.84C89C178D6@www2.open-std.org> <20081107001626.DACBFC178D6@www2.open-std.org> <20081107172923.2F102CA343A@www2.open-std.org> <20081107181649.95C87CA343A@www2.open-std.org> In-Reply-To: <20081107181649.95C87CA343A@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2008 21:29:20.0259 (UTC) FILETIME=[E53DBD30:01C9411F] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk N.M. Maclaren wrote: > > The (simplified) issue is whether SYNC MEMORY is allowed to wait until the > image that owns the data it is accessing reaches the next image control > statement. No more than that. > I would have to say no to the idea of allowing SYNC MEMORY to wait for other images to arrive at an image control statement. It lacks an exclusion for volatile coarrays. For the important case of the spin-loop synchronization you could end up with a hung program. Even in the non-volatile case, I don't see it as necessary. Finally, it is inconsistent with the semantics that SYNC MEMORY is a local operation (irrespective of how it might be actually implemented). > Yes, it would be possible to introduce a TIMEOUT value into SYNC MEMORY, > and set STAT if it were exceeded, but that wouldn't help. All it would > do is to allow a cautious programmer to diagnose the deadlock from within > the program, rather than having it show up as a hung program. It wouldn't > make it any easier to write portable code. > > The standard wording is sufficiently "processor dependent" that an implementation is already allowed to associate a specific STAT value with a timeout condition. It would not be portable, though a single named constant in a module might be all that is required for easy porting. I agree that this is not the desired answer to the original question. 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