On 25/10/2026 10:53, Konstantin Ananyev wrote:
On 25/10/2026 07:44, Konstantin Ananyev wrote:
It follows from the standard (5.1.2.4 Multi-threaded executions and
data races):
Two expression evaluations conflict if one of them modifies a
memory location and the
other one reads or modifies the same memory location. [...]
Well, that's why people invented different synchronization methods:
mutexes, rcu, etc. :)
If you want to protect your data against data-races it soesn't mean
yopu have to make
all your data reads/writes atomic - you need to select a proper
sync mechanism around
it, so you can keep using normal reads/writes for the data itself.
BTW, just blindly making data reads/writes atomic doesn't guarantee
that there will be
no race conditions.
What you're saying is covered by the "neither happens before the
other" clause below. In our case there are no mutexes, rcu, etc. that
make the write happen before the read, or the read happen before the
right. So the paragraph applies.
Ok, can we probably return to my initial question:
in the code under discussion: where do you see a race condition,
and how exactly your changes fix it?
I see undefined behaviour according to the definition below. This
definition depends on actions "at least one of which is not atomic", so
making all the actions atomic removes one of the conditions for the
undefined behaviour, making the behaviour defined.
The execution of a program contains a data race if it contains
two conflicting actions in
different threads, at least one of which is not atomic, and
neither happens before the
other. Any such data race results in undefined behavior.
