From owner-sc22wg5@open-std.org Wed Apr 21 23:10:32 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 E0F4CC4EA18; Wed, 21 Apr 2010 23:10:32 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ironport1.lbl.gov (ironport1.lbl.gov [128.3.41.47]) by www2.open-std.org (Postfix) with ESMTP id C33E4C4E9FA for ; Wed, 21 Apr 2010 23:10:28 +0200 (CET DST) X-Ironport-SBRS: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAA8Gz0uAAwU8/2dsb2JhbACdBL1fAoJyghsEgzQ X-IronPort-AV: E=Sophos;i="4.52,252,1270450800"; d="scan'208";a="129654782" Received: from angilas.lbl.gov (HELO angilas.localnet) ([128.3.5.60]) by ironport1.lbl.gov with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2010 14:09:38 -0700 From: Aleksandar Donev Organization: LBL To: WG5 Subject: Re: (j3.2006) (SC22WG5.4252) Question on locks Date: Wed, 21 Apr 2010 14:09:37 -0700 User-Agent: KMail/1.11.2 (Linux/2.6.28-17-generic; KDE/4.2.2; x86_64; ; ) References: <20100421204947.D8CC7C178DA@www2.open-std.org> In-Reply-To: <20100421204947.D8CC7C178DA@www2.open-std.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201004211409.37292.adonev@lbl.gov> Sender: owner-sc22wg5@open-std.org Precedence: bulk Hi Reinhold, I remember that we argued about this a lot (especially with someone on the C++ committee that was urging us to eliminate the implicit sync memory from locks, which was maybe when and why we did it), but I cannot recollect the details without looking at paper trails (this happened at the WG5 meeting in Vegas where we had long arguments about what sync memory and atomics really mean...). 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. Aleks On Wednesday 21 April 2010, Reinhold Bader wrote: > Does this not imply that in certain situations it may be necessary to > explicitly execute a > SYNC MEMORY after successfully acquiring a lock? In particular, is > not such a statement > required immediately after the statement > > LOCK(queue_lock) ! New segment A starts > > in Note 8.45 since otherwise a register-stored value of > work_queue_size might be used, > overlooking the update of its memory location by a remote image? -- Aleksandar Donev, Ph.D. Luis W. Alvarez Postdoctoral Fellow Center for Computational Sciences and Engineering (https://ccse.lbl.gov) Lawrence Berkeley National Laboratory (http://www.lbl.gov) E-mail: adonev@lbl.gov Phone: (510) 486-5782 Fax: (510) 486-6900 Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720 Web: http://cims.nyu.edu/~donev/