Re: 6.55 Built-in Functions for Memory Model Aware Atomic Operations

[Jonathan Wakely <jwakely.gcc@gmail.com>]

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:Note that the ‘__atomic’ builtins assume that programs will conform 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 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