From owner-sc22wg5@open-std.org Thu Apr 22 00:19:58 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 67740C4EA18; Thu, 22 Apr 2010 00:19:58 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by www2.open-std.org (Postfix) with ESMTP id BE9CBC4E9FA for ; Thu, 22 Apr 2010 00:19:53 +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]:40949) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1O4iGv-0001kP-Gt (Exim 4.70) (return-path ); Wed, 21 Apr 2010 23:19:53 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1O4iGv-0000L1-76 (Exim 4.67) (return-path ); Wed, 21 Apr 2010 23:19:53 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 21 Apr 2010 23:19:53 +0100 Date: 21 Apr 2010 23:19:53 +0100 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.4254) (j3.2006) Question on locks Message-ID: In-Reply-To: <20100421211846.2761BC4E9FA@www2.open-std.org> References: <20100421204947.D8CC7C178DA@www2.open-std.org> <20100421211033.11C11C4E9FA@www2.open-std.org> <20100421211846.2761BC4E9FA@www2.open-std.org> X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Apr 21 2010, Reinhold Bader wrote: >Aleksandar Donev schrieb: >[...] >> As a programmer, I hope that a SYNC MEMORY is not required when using >> LOCKS. The latter is meant to be used for user-defined ordering, i.e., >> in cases where the compiler cannot determine that some ordering might >> occur. For LOCK/UNLOCK this is clearly spelled out and so compilers >> cannot optimize in ways that break programs that conform to the segment >> ordering rules. >> >While I share this hope, the description of SYNC MEMORY together with >the spin lock example >Note 8.41 appears to contradict this. From Note 8.41 I conclude that >SYNC MEMORY serves two >purposes > >(1) prevent code movement across the segment boundary >(2) reload coarrays from memory upon first reference after the new >segment starts > >and I have the feeling that (1) is addressed by the semantics of locks, >but (2) isn't. No, I think that you have misunderstood. What locks don't provide is a barrier - i.e. a polint at which two images synchronise, and everything before is before, and everything after is after. They provide a one-way ordering. Specifically, 8.5.6 paragraph 5 specifies that SYNC MEMORY is not needed in the case where a segment ends in an UNLOCK statement, and another segment starts with a LOCK statement on the same variable. In that case, the first segment precedes the second. However, the segment preceding the LOCK is unordered with respect to the sequence following the UNLOCK. NOTE 8.41 could be improved by changing the namwe LOCKED, because it ISN'T using locks! It's using atomics. They do not synchronise memory. Regards, Nick Maclaren.