From owner-sc22wg5@open-std.org Fri Jun 12 10:32:29 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 02791C4596B; Fri, 12 Jun 2009 10:32:28 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by www2.open-std.org (Postfix) with ESMTP id 520CBC178E5 for ; Fri, 12 Jun 2009 10:32:03 +0200 (CET DST) 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-2.csi.cam.ac.uk ([131.111.8.54]:36182) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:nmm1) id 1MF2B9-0007Ny-1C (Exim 4.70) for sc22wg5@open-std.org (return-path ); Fri, 12 Jun 2009 09:32:03 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1MF2B9-0005GI-BW (Exim 4.67) for sc22wg5@open-std.org (return-path ); Fri, 12 Jun 2009 09:32:03 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 12 Jun 2009 09:32:03 +0100 Date: 12 Jun 2009 09:32:03 +0100 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.4009) (j3.2006) New summary of coarrays Message-ID: In-Reply-To: <20090611234024.3D012C4596B@www2.open-std.org> References: <20090609092023.32AF5C178DC@www2.open-std.org> <20090609093907.2863CC178DC@www2.open-std.org> <4A2E63B2.6020400@cray.com> <4A306193.5050708@nag-j.co.jp> <20090611234024.3D012C4596B@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 Jun 12 2009, Bill Long wrote: > >> No, as I understand it existing hardware and physical constraints >> encourages some vendors not to have global consistency; *and* we allow >> them not to have global consistency. > >I didn't see any relation to global consistency here. The context was >user written synchronization schemes. The issue is whether the atomic >operations take near-infinite time to execute. No, that's not so. It is the only likely problem with the specific example in 8.39, which involves a single variable and two images, but you start getting global consistency problems once you have more than two images, even with a single variable. Let's start with a variable X, initialised to zero. Image A processes for a bit, and then sets it to 1. Image B waits until it is non-zero, processes for a bit and sets it to 2. Image C waits until it is non-zero, processes for a bit, waits until it is > 1, processes for a bit, and sets it to 3. And so on. The question is whether any image (say, P) can see the value of X increase and then reduce again. Obviously, it may not see all values from 0 upwards. >> As for "confusing to an ordinary user", not nearly as confusing as >> getting wildly different answers or program hangs/crashes from the same >> data on the same machine on a Thursday. > >The same machine should have pretty consistent performance for a single >atomic memory operation. Don't bet on it. Even that isn't universal, and I have seen it fail. On complicated systems, you can get weird effects - and some of the weirdest I saw were on an SGI Origin, which purported to guarantee sequential consistency. 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