Re:How to trigger races reliably in the Linux kernel
by zozbot234 on Tuesday May 05, 2020 @09:29AM
(#23079801)
This is not a "data race" in a formal sense. A data race involves multiple threads accessing a non-atomic data object in ways that might result in an unintended and inconsistent state if the accesses overlap. That's always a bug.
Re:How to trigger races reliably in the Linux kernel
by jfkebwjsbx on Tuesday May 05, 2020 @09:58AM
(#23080055)
A data race does not necessarily imply a bug, even within your definition (which is only relevant for classical multithreaded applications).
Re:How to trigger races reliably in the Linux kernel
by steerablesafe on Tuesday May 05, 2020 @11:11AM
(#23080855)
In C++ a data race is UB, so it is most definitely always a bug there.
Re:How to trigger races reliably in the Linux kernel
by CodesInChaos on Tuesday May 05, 2020 @12:29PM
(#23081791)
The C++ standard's definition of a datarace only applies to ordinary memory access and rules those cases UB. But if you port such code to use relaxed load/store operations it's just as racey, but no longer UB. I'd consider still consider those cases data races, even though they don't meet the C++ standard's definition of them.
Re:How to trigger races reliably in the Linux kernel
by steerablesafe on Thursday May 07, 2020 @08:30AM
(#23102200)
Then you probably don't consider Rust datarace free as well.
That's a data race, the result will vary between executions because the row order will be different depending on how fast the various servers respond, but acknowledging that the order is not-well defined or guaranteed makes this data race accomodatable and even useful, since that gives a performance benefit compared to any solution that needs to ensure a specific order of these rows.