From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24979 invoked by alias); 27 Feb 2018 16:21:02 -0000 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 Received: (qmail 24967 invoked by uid 89); 27 Feb 2018 16:21:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*f:sk:1374244, rmws, H*i:sk:1374244, RMWs X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Feb 2018 16:21:00 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 215027D845; Tue, 27 Feb 2018 16:20:59 +0000 (UTC) Received: from ovpn-118-0.ams2.redhat.com (unknown [10.36.118.0]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B296E1C725; Tue, 27 Feb 2018 16:20:57 +0000 (UTC) Message-ID: <1519748456.15077.770.camel@redhat.com> Subject: Re: Fw: GCC interpretation of C11 atomics (DR 459) From: Torvald Riegel To: Ruslan Nikolaev Cc: Szabolcs Nagy , "nd@arm.com" , Alexander Monakov , Florian Weimer , gcc@gcc.gnu.org Date: Tue, 27 Feb 2018 16:40:00 -0000 In-Reply-To: <1374244604.4526352.1519737372145@mail.yahoo.com> References: <1615980330.4453149.1519617655582.ref@mail.yahoo.com> <1615980330.4453149.1519617655582@mail.yahoo.com> <108651736.4493788.1519629845236@mail.yahoo.com> <1519672046.15077.675.camel@redhat.com> <1175928742.4904141.1519673957549@mail.yahoo.com> <487848793.5030239.1519685142961@mail.yahoo.com> <1519730046.15077.736.camel@redhat.com> <1425399437.5330155.1519736166191@mail.yahoo.com> <4b2ab132-63e7-ce20-90e0-58632c60e07a@arm.com> <1374244604.4526352.1519737372145@mail.yahoo.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00237.txt.bz2 On Tue, 2018-02-27 at 13:16 +0000, Ruslan Nikolaev via gcc wrote: > > 3) Torvald pointed out further considerations such as users expecting lock-free atomic loads to be faster than stores. > > Is it even true? Is it faster to use some global lock (implemented through RMW) than a single RMW operation? If you use this global lock, you will not get loads faster than stores. If GCC declares a type as lock-free, atomic loads on this type will be natively supported through some sort of load instruction. That means they are faster than stores under concurrent accesses, in particular when there are concurrent atomic loads (for all major HW we care about). If there is no natively supported atomic load, GCC will not declare the type to be lock-free. Nobody made statement about performance of locks vs. RMWs.