News for hackers. Stuff that matters.
Re:How to trigger races reliably in the Linux kernel by pjc50 on Tuesday May 05, 2020 @10:31AM (#23080387)
> What terminology do you use to describe something that is non-deterministic due to timing, but correct?

"Non-deterministic" works? However, I'm arguing that nondeterministic results from deterministic input are themselves a mild form of bug, like a compiler warning or "code smell".

Perhaps we also have to talk about causality and serialisability, clocks and timestamping. In a concurrent or distributed system it may not be easy to determine what order things happen in without unreasonable effort or performance impairment, but if so the system has to be designed so that doesn't matter.

> Think of two worker threads pushing entires to a synchronised log. It's non-deterministic which order they arrive in the log, as different schedulings and other things will cause the threads to run in different orders (they 'race' to put entries in the log, we say), but it's not a bug, and it's not lock-free because the log is synchronised.

Those I would call independent. Unless they're acting on something in common, in which case having the transactions serialised as A before B then logged as B before A is immensely annoying.

Re:How to trigger races reliably in the Linux kernel by lostcolony on Tuesday May 05, 2020 @11:46AM (#23081291)
"Non-deterministic" totally works, but it's not necessarily a bug or even a code smell even if deterministic inputs lead to non-deterministic results. The order a series of parallel network calls returns is non-deterministic, for instance, but hardly a bug.

Otherwise, yes, agreed on all counts. It's telling that even when posing the question of what other term to use besides race condition, the op used 'non-deterministic'.