From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 000A93955423 for ; Wed, 21 Jul 2021 13:09:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 000A93955423 Received: by mail-wm1-x32b.google.com with SMTP id l17-20020a05600c1d11b029021f84fcaf75so3404648wms.1 for ; Wed, 21 Jul 2021 06:09:42 -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=PddLN54iExdVN5NRSKOzuGMPgLLjRDJg/zcUWZ3m9f0=; b=UbBju/YldPGrXmNi9zkcfJwxOqRBD5dtHpmD04xLtesIc7Cu6E59gUKgJsQRQijssl rO3esfyZe+7LiimHpeZf1+PVbL7wbJYJ1GIgscWdced32apVlgZZbgenFEbSqigJF0nW DTBSh7Xg+ZVcCLsh/hVaqQAy3fE5/9iJ3GBZMZ4DcAtZQ3IvMVyavaq6zS0cs8gjvtSr WY/15XTBKUyI4O2LQCiASTL8PEExK3e5iApLWRmxH08K6XmlvkarnAz2TosiyEOGJWDE X0VwHTyy7wnOEIuE3mOwf86Nsb3hEZI0wuCqh/LOg7/L2p52KpN8ADB8TKPU9uM6l2R/ lAWA== X-Gm-Message-State: AOAM530Rgr0aXmrInSXDve3bvzygsX2a3kUlyV7/RuxGS6JodrKWThWQ Zxq7ChLkKExWYu4nZvDg3jtAsqjT2I+UinufuUE= X-Google-Smtp-Source: ABdhPJwEraCJzfHhXnkADnnJAN0zW6ky5SztA0YMfwU0Gx8b6qDe5qWUQ8+EEKqCErU1UPm5hwIAONzYDr28iPNOE+g= X-Received: by 2002:a05:600c:198c:: with SMTP id t12mr28733719wmq.106.1626872981953; Wed, 21 Jul 2021 06:09:41 -0700 (PDT) MIME-Version: 1.0 References: <49b2-60f7d900-cf7-23647ec0@27167096> In-Reply-To: From: Jonathan Wakely Date: Wed, 21 Jul 2021 14:09:30 +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.6 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 13:09:46 -0000 On Wed, 21 Jul 2021 at 10:49, Jonathan Wakely wrote: > > 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 (= https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html) says:No= te that the =E2=80=98__atomic=E2=80=99 builtins assume that programs will c= onform to the C++11 memory model. In particular, they assume that programs = are free of data races. See the C++11 standard for detailed requirements. > > > > > > I think the second sentence is a bit misleading because atomics shoul= d handle data races. > > > > It depends what you mean "handle data races". You can just sprinkle Oops, and that should say you CAN'T just sprinkle atomics ... ! > > 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 no= t 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