4 ms·
Let's say you have query that returns a bunch of rows from a sharded database by asking every shard and naively combining their responses by simply forwarding a
by PeterisP 7y ago
Let's say you have query that returns a bunch of rows from a sharded database by asking every shard and naively combining their responses by simply forwarding all rows as soon as you receive them.
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.
- zozbot234 7y agoThis 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.
- jfkebwjsbx 7y agoA data race does not necessarily imply a bug, even within your definition (which is only relevant for classical multithreaded applications).
- steerablesafe 7y agoIn C++ a data race is UB, so it is most definitely always a bug there.
- CodesInChaos 7y agoThe 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.
- steerablesafe 7y agoThen you probably don't consider Rust datarace free as well.