[ajross]

That definition seems to conflate "determinism" (something largely impossible to achieve in asynchronously parallel systems) with "correctness" (an abstracted property of a system that doesn't have anything to do with determinism per se). It just doesn't seem useful.

No, in overwhelmingly common usage, programmers use the term "race condition" as a category of software bug. We mean it in the correctness sense, not the one used in the linked article nor your reference. You'd be met with some very weird stares if you tried to explain how arbitrary SMP ordering of log entries or whatever was a "race condition".

[bheadmaster]

> No, in overwhelmingly common usage, programmers use the term "race condition" as a category of software bug

This was exactly my point.

    race condition = incorrect behavior
    non-determinism = correct behavior

Language is tricky sometimes.

[chrisseaton]

> That definition seems to conflate "determinism" (something largely impossible to achieve in asynchronously parallel systems)

There are plenty of examples of entirely deterministic parallel models. Fork-join for one.

[ajross]

I think you missed the point. Let me expand.

I mean, yes, what you say is true, but it just amounts to saying "synchronization is a solvable problem". At their core, ALL synchronization paradigms (spin polling, interrupt masking, OS-managed process suspend, hardware memory barriers, weird lockless tricks like Dekker's algorithm, you name it) can be understood to be ways of enforcing "para-determinism" on environments that don't provide it.

In SMP, things don't happen in reliable orders. They don't. They never will. They can't. But your hardware and OS platforms are smart and provide trickery so that at least you can guarantee that "some" things happen in reliable orders. And then you construct software such that correct behavior is dependent only on that subset of ordering and not everything.

Because there is no determinism in SMP, only that which you construct.

[chrisseaton]

If you can't observe the non-determinism, then is it really non-determinism?

Your processor executes a single thread of instructions also in a non-deterministic order, based on complex internal state. We'd never say it was non-deterministic, as you can't detect it.

[ajross]

You can absolutely observe non-determinism. That's what a race condition bug is, after all. You can also observe benign nondeterminism every day in anything that records ordering. Go do a parallel make, then do it again and observe the ordering of the mtime values in the intermediate artifacts. It won't be the same.

And FWIW: CPU-internal instruction reordering is observable too, though the details there get complicated. x86 hides (almost!) all the complexity from you, but ARM's OOO is leakier and requires careful attention to memory barriers.

[smallnamespace]

It's visible from the perspective of the software engineer who molds non-deterministic abstractions into predictable interactions for the user.