From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31730 invoked by alias); 26 Jul 2013 21:35:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 31721 invoked by uid 89); 26 Jul 2013 21:35:09 -0000 X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 26 Jul 2013 21:35:09 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6QLYl9O005636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Jul 2013 17:34:47 -0400 Received: from [10.10.60.240] (vpn-60-240.rdu2.redhat.com [10.10.60.240]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r6QLYk1B011525; Fri, 26 Jul 2013 17:34:47 -0400 Message-ID: <51F2EB76.7020307@redhat.com> Date: Fri, 26 Jul 2013 22:29:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andi Kleen CC: gcc-patches , hp@bitrange.com Subject: Re: [PATCH] Add atomic type qualifier References: <51F2AEB1.60408@redhat.com> <87ob9pm9gt.fsf@tassilo.jf.intel.com> <51F2CEFB.1040000@redhat.com> <87fvv1m3cs.fsf@tassilo.jf.intel.com> In-Reply-To: <87fvv1m3cs.fsf@tassilo.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg01295.txt.bz2 On 07/26/2013 05:13 PM, Andi Kleen wrote: > Andrew MacLeod writes: >> The way the standard is defined, any implicit operation like that is >> seq_cst. If you want something other than seq-cst, you have to >> explicitly call atomic_store (&x, 0, model). > Thanks. > > This doesn't sound like a good default for x86. seq_cst requires > somewhat expensive extra barriers that most people most likely don't > need. > Its the only truly safe default for a multi-threaded environment. These are the same defaults you get with C++11 as well if you don't explicitly use a memory model in your atomic operations: ie __int_type load(memory_order __m = memory_order_seq_cst) const noexcept So if you don't want seq-cst, you need to specify exactly what you do want. Andrew