6.55 Built-in Functions for Memory Model Aware Atomic Operations

6.55 Built-in Functions for Memory Model Aware Atomic Operations

[Amar Memic]

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.
Especially, interleaving read/write or write/write operations should be well-defined.
If you assume that programs are free of data races, then you could not implement spinlock based on these atomics, for example.
I hope you can help me to interpret the paragraph in the right manner. 

Thanks in advance
Amar Memic

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

[Jonathan Wakely]

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. 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

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

[Jonathan Wakely]

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

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

[Jonathan Wakely]

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: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

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 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