[shwestrick]

Author here. I think it would be very strange to say that this code does not have a race condition. The whole point of the term is to identify circumstances where non-deterministic timing of events influences how you reason about correctness, which is exactly what we're doing here.

[bheadmaster]

I've personally only heard the term "race condition" used to refer to bugs that have their source in non-deterministic execution of programs. In most cases, they refer to a specific sequence of events that the programmer did not foresaw, which lead to incorrect computation.

Using the term "race condition" in context of correct programs would make it cover exactly the same universe of programs as the term "non-determinism". I that think the distinction, however trivial (race condition = incorrect behavior, non-determinism = correct behavior), is still useful.

Great article, by the way. I did not mean to criticize it in any way. My "slight nitpick" about meaning of the words is really just that - a nitpick :)

[shwestrick]

Ah I see. That's a fair point!

When talking about this kind of stuff to people who are unfamiliar with, say, lock-freedom, I've found that "non-determinism" is too vague --- people start thinking about things like randomness, or user interaction, etc. In contrast, the term "race condition" seems to hit the nail on the head.

But certainly, "race condition" also carries with it a bit of baggage ;)

[throwawaymaths]

I work in the Erlang VM, and we always say stuff like "whether your output to IO hits first ot the logger line outputs to IO first is a race condition". Neither is substantively wrong, and you could definitely say "it's a race!", grab some popcorn, and watch the electrons do their thing.

[kazinator]

If we put on a cynical hat, your page reads like "I've never heard of lock-free algorithms based on atomic operations. I therefore must have just invented it and I get to name it: how about beneficial use of race conditions?"

[shwestrick]

Whoa, uhh, I mean, that's an extremely unfair and inaccurate characterization.

[kazinator]

Sure, and one that one can avoid bringing on oneself by not abusing/twisting/redefining common terminology.

[bheadmaster]

Eh, I personally wouldn't be so hard on someone because of language. Words don't have definite meanings on their own, it's our general agreement that makes them meaningful. And the meaning of words are often overlapping, shades-of-grey kind of deal, with even more subtle differences in individual understanding of them. Language is hard.

Moreover, polite explanations may bring enlightenment, but aggressive scoldings are almost guaranteed stop people from accepting your words, even if they're true, because in order to accept their truth, they have to accept the unpleasant implications of your words.

I think learning should generally be as pleasant as possible. Putting the work in is hard enough as it is.

[kazinator]

> I think learning should generally be as pleasant as possible.

If you want pleasant learning on the Internet, don't "learn by teaching" through blogs that mislead other learners, even if only in terminology use.

People will tear that apart.

[bheadmaster]

According to the Encyclopedia of Parallel Computing (mentioned in one of the sibling sub-comments of my original comment), you and I are both wrong in what we consider a "race condition". Of course, whether or not the source is an authority on the subject when the popular usage of the word refers to a different concept is questionable, but there's at least a possibility that we're both wrong.

Regardless, that's still one more reason not to be unpleasant to people when correcting them - you might just find yourself in the wrong.