From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19632 invoked by alias); 1 Oct 2011 06:56:22 -0000 Received: (qmail 19619 invoked by uid 22791); 1 Oct 2011 06:56:21 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,TW_CX X-Spam-Check-By: sourceware.org Received: from mail4-relais-sop.national.inria.fr (HELO mail4-relais-sop.national.inria.fr) (192.134.164.105) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 01 Oct 2011 06:56:05 +0000 Received: from ip-133.net-81-220-116.brest.rev.numericable.fr (HELO laptop-mg.local) ([81.220.116.133]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2011 08:56:02 +0200 Date: Sat, 01 Oct 2011 06:56:00 -0000 From: Marc Glisse Reply-To: gcc@gcc.gnu.org To: Andrew MacLeod cc: Lawrence Crowl , Benjamin Kosnik , Richard Henderson , Aldy Hernandez , GCC Subject: Re: C++11 atomic library notes In-Reply-To: <4E862864.2010607@redhat.com> Message-ID: References: <4E862864.2010607@redhat.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00002.txt.bz2 On Fri, 30 Sep 2011, Andrew MacLeod wrote: > I've been working on GCC's C++11 atomic implementation. Cool! > In discussions with > Lawrence, I've recently discovered a fundamental change in what libstdc++-v3 > is likely to provide as far as an implementation. > > Previously, header files provided a choice between a locked or a lock-free > implementation, preferring the lock-free version when available on the > architecture and falling back to the locked version in other cases. > > Now the thought is to provide lock-free instructions when possible, and fall > back to external function calls the rest of the time. These would then be > resolved by an application or system library. > > If proceeding with that change, it would be convenient to make the same calls > that other implementations are going to use, allowing OS or application > providers to simply provide a single library with atomic routines that can be > used by multiple C++11 compilers. > > Since GCC 4.7 stage 1 is going to end shortly and it would be nice to get the > cxx-mem-model branch integrated, I quickly wrote up what the current plan for > the branch is regarding these external calls and such and brought up a couple > of issues. Its located in the gcc wiki at: > http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary "The compiler must ensure that for any given object, it either ALWAYS inlines lock free routines, OR calls the external routines. For any given object, these cannot be intermixed." Why? You give an example explaining why it is fine to link 386 and 486 objects, and I cant see the difference. Not that I'm advocating mixing them, just wondering whether it really matters if it happens (by accident). I assume that locks are supposed to be implemented in terms of those functions too (it sounds like lock uses atomic which uses lock ;-) For the atomic version of a user-defined "small" POD type, do you intend to query the compiler about the presence of a volatile member to dispatch to the right function? The design looks a lot like: http://libcxx.llvm.org/atomic_design_a.html which is good since the main point seems to be to share it between implementations. Are there others on board? -- Marc Glisse