From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id BA6ED389900E for ; Wed, 21 Jul 2021 09:49:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA6ED389900E Received: by mail-wm1-x329.google.com with SMTP id u8-20020a7bcb080000b02901e44e9caa2aso617084wmj.4 for ; Wed, 21 Jul 2021 02:49:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n00KEwhjdkcej55ZDtOldRfwSAaRZk+BEp8fNZLhAxU=; b=NsjWQ9j1lodAGMbs1/Uc+EYCvgtqK1gDb3iQXoHA7I9W2Cib2T0tWPsCo8nDsklHAh t0l0zA5Dl5EVldAr5oIJ8C4wNZIl6HEYN12+V49z+UviRmQus7RYe5bHhssdV1lhyggX ztz7/xpu4yL7tRg/oeo10q7Fw6o+WRwk7y6I1J06JdnMsh24mS2F7wzur2wY9450Uk+z b9JGMxZYdY+oL/p1mmaSN4iprcF6mn38Q8Js2xHU5W6DOTDsEKYeGAU/ixmRLTxOIFVv s468cG5fMMBakqHE4czMIpKyrWnR1aFtnNzlZJ9mocf2cLVbeszlQxuUzKRo7Lq8mvZz 3Xtg== X-Gm-Message-State: AOAM531cti26kJPK4msZQR5tB00sJg4FyxivZyfpv8TUeDN2y4gQfpij kVkxg1DrJax+CF2ehNKkQa2ZWND+Qqjk7vJKfadhwvJc X-Google-Smtp-Source: ABdhPJwWMw8tEs/Qb1JNltmMjt2ZXjDKsbk3GYtxoXpm5zcaFWuRU2ZJcOmKib3Vox5Y5h9WD5xOGWeIfkPy9p2uhP8= X-Received: by 2002:a05:600c:2211:: with SMTP id z17mr36639447wml.17.1626860964871; Wed, 21 Jul 2021 02:49:24 -0700 (PDT) MIME-Version: 1.0 References: <49b2-60f7d900-cf7-23647ec0@27167096> In-Reply-To: From: Jonathan Wakely Date: Wed, 21 Jul 2021 10:49:13 +0100 Message-ID: Subject: Re: 6.55 Built-in Functions for Memory Model Aware Atomic Operations To: Amar Memic Cc: "libstdc++" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 09:49:27 -0000 On Wed, 21 Jul 2021 at 10:47, Jonathan Wakely wrote: > > This doesn't seem relevant to the libstdc++ list, as those built-in > functions are part of the compiler, not the std::lib. > > On Wed, 21 Jul 2021 at 09:22, Amar Memic wrote: > > > > > > Hi,6.55 Built-in Functions for Memory Model Aware Atomic Operations (ht= tps://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html) says:Note= that the =E2=80=98__atomic=E2=80=99 builtins assume that programs will con= form to the C++11 memory model. In particular, they assume that programs ar= e free of data races. See the C++11 standard for detailed requirements. > > > > I think the second sentence is a bit misleading because atomics should = handle data races. > > It depends what you mean "handle data races". You can just sprinkle > some atomics and assume you've removed data races. The C++11 memory > model requires that all potentially concurrent access to a memory > location are atomic. I should have said "all potentially concurrent accesses to a memory location where at least one is a write". See the precise definition I quoted below. > That means you can't use an atomic write in one > thread and a concurrent non-atomic read in another thread, because > that would be a data race. The __atomic built-ins assume that you > don't do that. > > > > Especially, interleaving read/write or write/write operations should be= well-defined. > > If all reads and writes use atomic operations, yes. > > > If you assume that programs are free of data races, then you could not = implement spinlock based on these atomics, for example. > > I think maybe your definition of "data race" doesn't match the > intended meaning here. You might be thinking of what is more correctly > called a "race condition". The C++ standard defines a "data race" > precisely: > > "The execution of a program contains a data race if it contains two > potentially concurrent conflicting actions, at least one of which is > not atomic, and neither happens before the other, except for the > special case for signal handlers described below. Any such data race > results in undefined behavior." > > This means a data race is a specific kind of race condition, which > results in undefined behaviour. > > See https://blog.regehr.org/archives/490 and > https://en.wikipedia.org/wiki/Race_condition#Data_race