From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12506 invoked by alias); 5 Oct 2011 04:14:44 -0000 Received: (qmail 12497 invoked by uid 22791); 5 Oct 2011 04:14:42 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_CX X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 04:14:27 +0000 Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p954EPQV023650 for ; Tue, 4 Oct 2011 21:14:25 -0700 Received: from qadc14 (qadc14.prod.google.com [10.224.32.142]) by wpaz17.hot.corp.google.com with ESMTP id p954E2ol011668 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 21:14:24 -0700 Received: by qadc14 with SMTP id c14so2641086qad.6 for ; Tue, 04 Oct 2011 21:14:24 -0700 (PDT) Received: by 10.150.196.9 with SMTP id t9mr1828628ybf.5.1317788064423; Tue, 04 Oct 2011 21:14:24 -0700 (PDT) Received: by 10.150.196.9 with SMTP id t9mr1828619ybf.5.1317788064186; Tue, 04 Oct 2011 21:14:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.13.6 with HTTP; Tue, 4 Oct 2011 21:14:04 -0700 (PDT) In-Reply-To: <4E862864.2010607@redhat.com> References: <4E862864.2010607@redhat.com> From: Jeffrey Yasskin Date: Wed, 05 Oct 2011 07:26:00 -0000 Message-ID: Subject: Re: C++11 atomic library notes To: Andrew MacLeod Cc: Lawrence Crowl , Benjamin Kosnik , Richard Henderson , Aldy Hernandez , GCC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes 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/msg00067.txt.bz2 On Fri, Sep 30, 2011 at 1:36 PM, Andrew MacLeod wrote: > I've been working on GCC's C++11 atomic implementation. In discussions wi= th > 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 f= all > 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 =A0by 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. =A0Its located in the gcc wiki at: > http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary > > Its my first cut at it, so hopefully its mostly correct :-) > > If anyone has any interest or input on this subject, the sooner it is > brought up the better! I wanted to comment on http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary#volatility. Say we have: typedef pair DWord; std::atomic shared_var; void thread1() { use(shared_var.load()); } void thread2() { // It's legal to add "volatile" in a pointer or reference cast. volatile std::atomic* v_shared_var =3D &shared_var; // Now this looks identical to an access to a real volatile object. v_shared_var->store(DWord(ptr, val)); } If, as the document proposes, "16 byte volatile will have to call the external rotines, but 16 byte non-volatiles would be lock-free.", and the external routines use locked accesses for 16-byte volatile atomics, then this makes the concurrent accesses to shared_var not thread-safe. To be thread-safe, we'd have to call the external routines for every 16-byte atomic, not just the volatile ones, and those routines would have to use locked accesses uniformly rather than distinguishing between volatile and non-volatile accesses. Not good. Even worse, on LL/SC architectures, every lock-free RMW operation potentially involves multiple loads, so this interpretation of volatility would prohibit lock-free access to all objects. I see two ways out: 1) Say that accessing a non-volatile atomic through a volatile reference or pointer causes undefined behavior. The standard doesn't say that, and the casts are implicit, so this is icky. 2) Say that volatile atomic accesses may be implemented with more than one instruction-level access. (2) is something like how volatile reads of 128-bit structs involve multiple mov instructions that execute in an arbitrary order. It's also unlikely to cause problems in existing programs because nobody's using volatile atomics yet, and they'll only start using them in ways that work with what compilers implement. Jeffrey