From owner-sc22wg5@open-std.org Thu Dec 4 10:10:23 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 09BDFCA5FE7; Thu, 4 Dec 2008 10:10:23 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by www2.open-std.org (Postfix) with ESMTP id 3FE78CA5FE4 for ; Thu, 4 Dec 2008 10:10:21 +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]:35815) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1L8AE1-000208-NP (Exim 4.70) for sc22wg5@open-std.org (return-path ); Thu, 04 Dec 2008 09:10:21 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1L8AE1-0000R7-7n (Exim 4.67) for sc22wg5@open-std.org (return-path ); Thu, 04 Dec 2008 09:10:21 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 04 Dec 2008 09:10:21 +0000 Date: 04 Dec 2008 09:10:21 +0000 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.3725) (j3.2006) Atomic stuff Message-ID: In-Reply-To: <20081204010617.D8437C4596D@www2.open-std.org> References: <20081203025222.12F4BC178E0@www2.open-std.org> <493626D6.9020006@llnl.gov> <20081204010617.D8437C4596D@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 Dec 4 2008, Van Snyder wrote: > >An ATOMIC attribute for a variable doesn't affect its representation: it >only affects how it is accessed or defined, within the scoping unit or >construct wherein it is specified. It requires both atomic references >and atomic updates. That's all. ... Regrettably, that is NOT true! There are virtually no systems that support atomic access to unaligned objects, and many compilers that allow ordinary objects to be unaligned. There used to be many systems where atomic accesses had to be to a particular size, which was not necessarily the size of any of Fortran's default types, and there may still be some. If you make ATOMIC simply an attribute, and allow it to be different in different scopes, all such systems would have to implement atomic accesses using locking, or risk the race condition. Given that benchmarketing rules, what do YOU think they will do? 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