* 6.55 Built-in Functions for Memory Model Aware Atomic Operations
@ 2021-07-21 8:20 Amar Memic
2021-07-21 9:47 ` Jonathan Wakely
0 siblings, 1 reply; 4+ messages in thread
From: Amar Memic @ 2021-07-21 8:20 UTC (permalink / raw)
To: libstdc++
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 6.55 Built-in Functions for Memory Model Aware Atomic Operations
2021-07-21 8:20 6.55 Built-in Functions for Memory Model Aware Atomic Operations Amar Memic
@ 2021-07-21 9:47 ` Jonathan Wakely
2021-07-21 9:49 ` Jonathan Wakely
0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Wakely @ 2021-07-21 9:47 UTC (permalink / raw)
To: Amar Memic; +Cc: libstdc++
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 6.55 Built-in Functions for Memory Model Aware Atomic Operations
2021-07-21 9:47 ` Jonathan Wakely
@ 2021-07-21 9:49 ` Jonathan Wakely
2021-07-21 13:09 ` Jonathan Wakely
0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Wakely @ 2021-07-21 9:49 UTC (permalink / raw)
To: Amar Memic; +Cc: libstdc++
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 6.55 Built-in Functions for Memory Model Aware Atomic Operations
2021-07-21 9:49 ` Jonathan Wakely
@ 2021-07-21 13:09 ` Jonathan Wakely
0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Wakely @ 2021-07-21 13:09 UTC (permalink / raw)
To: Amar Memic; +Cc: libstdc++
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-07-21 13:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-21 8:20 6.55 Built-in Functions for Memory Model Aware Atomic Operations Amar Memic
2021-07-21 9:47 ` Jonathan Wakely
2021-07-21 9:49 ` Jonathan Wakely
2021-07-21 13:09 ` Jonathan Wakely
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).