From owner-sc22wg5@open-std.org Fri Nov 7 23:09:33 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 53C1ACA5FE8; Fri, 7 Nov 2008 23:09:33 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by www2.open-std.org (Postfix) with ESMTP id BE505CA343A for ; Fri, 7 Nov 2008 23:09:32 +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]:48208) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:nmm1) id 1KyZWF-0002rs-IP (Exim 4.70) for sc22wg5@open-std.org (return-path ); Fri, 07 Nov 2008 22:09:31 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1KyZWF-0000lU-MN (Exim 4.67) for sc22wg5@open-std.org (return-path ); Fri, 07 Nov 2008 22:09:31 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 07 Nov 2008 22:09:31 +0000 Date: 07 Nov 2008 22:09:31 +0000 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.3649) (j3.2006) A comment on John Wallin's comments on Nick MacLaren's comments Message-ID: In-Reply-To: <20081107212925.53E6ECA343A@www2.open-std.org> 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> <20081107212925.53E6ECA343A@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 Nov 7 2008, Bill Long 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. I don't have a major problem with that, but the standard needs to say so, and to say exactly what it does permit. Currently, it doesn't. >Finally, it is >inconsistent with the semantics that SYNC MEMORY is a local operation >(irrespective of how it might be actually implemented). It is always a bad idea to specify something that is logically and physically unrealistic. Those semantics are not deliverable, in general. 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