From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 2C370385BF9D for ; Wed, 21 Jul 2021 09:48:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C370385BF9D Received: by mail-wr1-x42d.google.com with SMTP id m2so1495810wrq.2 for ; Wed, 21 Jul 2021 02:48:01 -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=gmYBLMbWSHoVN44eRYoFK07M0a6oEKVvbXLe9UmjAmY=; b=XW1XYIlh+K4gL43V7nazpZmhtrvvHzWCWX2JseMD6AodYgjNg+d5NQEfjSYUyihUZK UrCqo+FzRXOJ9RusQcb0sN1HY2X2CPV+hxKTdWFT/ppXgyhessGyZIre4jhzhzH8G+0c z5Mu0cIwp2G+T0ImTjyUMzwtUMdTXAPQJb+J+XMB6aisdnHSlQfVb/sUHxUu3iOAw4mx BCA0LK0+h+8ypyTqtWn+geDvuAqQyzOfhg/hPvJMirUlB+ISmb33rsxJNJPZBdslvVO5 9JR5Sm/Mu0SjRtBZIhB0CAOpzDjyxl2lS+HzrgbQCt9Imd4qv8JD6LI9wk8JCn7tCbSn A98w== X-Gm-Message-State: AOAM532mrgCxecjepnDa0peiyfj0JlY0l+b/ac6RMce03yX/A4QvXcjT paKbw3hVPIFhFydg1tofG60LI/4B7ftH4SrCF2U= X-Google-Smtp-Source: ABdhPJwgZkiFdbsyUd+0SPYmv48m6g3uOwrJGZRV+aQZLlFEttUQIMIMcXRXclTTAN181nM/8iLFFYBLU/gKHTc5Xio= X-Received: by 2002:adf:e805:: with SMTP id o5mr8970703wrm.321.1626860880190; Wed, 21 Jul 2021 02:48:00 -0700 (PDT) MIME-Version: 1.0 References: <49b2-60f7d900-cf7-23647ec0@27167096> In-Reply-To: <49b2-60f7d900-cf7-23647ec0@27167096> From: Jonathan Wakely Date: Wed, 21 Jul 2021 10:47:49 +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.8 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:48:04 -0000 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 (http= s://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html) says:Note t= hat the =E2=80=98__atomic=E2=80=99 builtins assume that programs will confo= rm 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 should ha= ndle 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. 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 w= ell-defined. If all reads and writes use atomic operations, yes. > If you assume that programs are free of data races, then you could not im= plement 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