From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18508 invoked by alias); 2 Oct 2011 08:40:31 -0000 Received: (qmail 18034 invoked by uid 22791); 2 Oct 2011 08:40:28 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail1-relais-roc.national.inria.fr (HELO mail1-relais-roc.national.inria.fr) (192.134.164.82) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 02 Oct 2011 08:40:14 +0000 Received: from afontenayssb-151-1-53-93.w82-121.abo.wanadoo.fr (HELO laptop-mg.local) ([82.121.88.93]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Oct 2011 10:40:12 +0200 Date: Sun, 02 Oct 2011 08:40:00 -0000 From: Marc Glisse Reply-To: gcc@gcc.gnu.org To: Andrew MacLeod cc: gcc@gcc.gnu.org, Lawrence Crowl , Benjamin Kosnik , Richard Henderson , Aldy Hernandez Subject: Re: C++11 atomic library notes In-Reply-To: <4E879E4B.9030106@redhat.com> Message-ID: References: <4E862864.2010607@redhat.com> <4E879E4B.9030106@redhat.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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/msg00007.txt.bz2 On Sat, 1 Oct 2011, Andrew MacLeod wrote: > On 10/01/2011 02:55 AM, Marc Glisse wrote: >> >> "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). > > If we have an architecture which we cannot generate one of the functions for, > say __atomic_load_16, then it will have to use whatever the library supplies. > If you continues to generate all the rest of the __atomic builtins for 16 > bytes using lock free instructions, and the call to the library turns out to > be a locked implementation at runtime, then atomic support for 16 byte > objects is broken. The load thinks its getting a lock, but none of the other > routines pay any attention to locks. So if one atomic operations requires > then library, they all do in order to get consistent behaviour. Ah ok, I had understood: * if __atomic_store_8 is inlined on line 18, it should also be inlined on line 42 when instead it is: * we can't have a locked addition and a lock-free subtraction (hence the __atomic_is_lock_free which only takes a size as argument) Makes perfect sense, thank you for the precision. By the way, does it make sense to work atomically on a 16 byte object, and also work atomically on its first 8 bytes, thus potentially requiring __atomic_is_lock_free not to depend on the size? -- Marc Glisse