Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Race Conditions Can Be Useful for Parallelism

shwestrick.github.io

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Race Conditions Can Be Useful for Parallelism

#61

Post by throwawaymaths »

bheadmaster wrote: post #28
shwestrick wrote: post #17

Earlier quoted context omitted.

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.

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-determi…

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.

Re: Race Conditions Can Be Useful for Parallelism

#62

Post by squeaky-clean »

bheadmaster wrote: post #56
squeaky-clean wrote: post #54

Earlier quoted context omitted.

> This article needs additional citations for verification. (July 2010). The definition you quote has no linked citation on Wikipedia. Usually a good sign that you should not treat those statements as definitive. A good Wikipedia article should not state any "facts" without a direct means of verification. Otherwise it's considered "original research" and against the wiki policy for a high quality article. https://en.…

I used Wikipedia in order to have some kind of reference, but I was fairly sure of the meaning beforehand. Searching the internet for "race condition definition" and taking the top few results brings several definitions that all agree in spirit with the Wikipedia one (see below). If you know of any more reliable source that doesn't agree with Wikipedia on the definition of "race condition", please post it here. This…

> If you know of any more reliable source that doesn't agree with Wikipedia on the definition of "race condition", please post it here.

Other commenters have already covered that. The links you shared aren't good primary sources, and probably took their definition from Wikipedia itself, creating a circular reference issue.

Re: Race Conditions Can Be Useful for Parallelism

#63

Post by remram »

chrisseaton wrote: post #47
remram wrote: post #34

Earlier quoted context omitted.

By this definition, every access to a shared resource is a race condition, e.g. even when properly acquiring a lock. It is common knowledge that you introduce locks to remove race conditions so I would say something is definitely missing from the definition.

Usually you’re adding locks not to remove the race condition but to make them not a bug.

That is a valid definition but it's not the one used by everyone I know and work with. A race condition is a fault, just like a SQL injection; it could easily have referred to a programming technique but it doesn't.

Re: Race Conditions Can Be Useful for Parallelism

#64

Post by bheadmaster »

chrisseaton wrote: post #60
bheadmaster wrote: post #57

Earlier quoted context omitted.

Hey, I've just downloaded PADUA ( http://dx.doi.org/10.1145/2633685 ), and skimming through it, I can't find a single mention of the phrase "race condition". Is this the paper you're referring to? If not, could you please provide a reference to which PADUA you're referring to? I'd really like to read more on the subject, especially if the source is, as you claim, an industry reference.

David Padua, https://link.springer.com/referencework/10.1007/978-0-387-09... .

Thanks!

If you have any relevant information, would you care to elaborate more on why is it considered industry standard and how did it gain such status?

This is the first time I'm hearing of both the author and the book (which probably says more about me), and it seems kind of odd that the definition differs from what is usually taught in class (at least mine). Of course, it wouldn't be the first time that popular use of some word differs from its original intended meaning, but I'm just interested in the wider historical context.

Thanks again.

Re: Race Conditions Can Be Useful for Parallelism

#65

Post by bheadmaster »

kazinator wrote: post #46
bheadmaster wrote: post #43

Earlier quoted context omitted.

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 a…

> 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.

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.

Re: Race Conditions Can Be Useful for Parallelism

#66

Post by bheadmaster »

squeaky-clean wrote: post #62
bheadmaster wrote: post #56

Earlier quoted context omitted.

I used Wikipedia in order to have some kind of reference, but I was fairly sure of the meaning beforehand. Searching the internet for "race condition definition" and taking the top few results brings several definitions that all agree in spirit with the Wikipedia one (see below). If you know of any more reliable source that doesn't agree with Wikipedia on the definition of "race condition", please post it here. This…

> If you know of any more reliable source that doesn't agree with Wikipedia on the definition of "race condition", please post it here. Other commenters have already covered that. The links you shared aren't good primary sources, and probably took their definition from Wikipedia itself, creating a circular reference issue.

Regardless, if you yourself happen to know any sources that weren't covered in other comments, please share them.

I remember learning about race conditions in college, and they were always mentioned in the context of bugs - that's why I took Wikipedia itself for granted, as its definition fit my current understanding of the word.

It seems to be a case of popular usage of the word differing from the original. It also raises a question of whether or not the original intended meaning is the authority, if the majority of programmers use it in a different way. Who should, in general, be the authority on the meaning of a word? But that's more of a philosophical question, I suppose.

Re: Race Conditions Can Be Useful for Parallelism

#67

Post by chrisseaton »

bheadmaster wrote: post #64
chrisseaton wrote: post #60

Earlier quoted context omitted.

David Padua, https://link.springer.com/referencework/10.1007/978-0-387-09... .

Thanks! If you have any relevant information, would you care to elaborate more on why is it considered industry standard and how did it gain such status? This is the first time I'm hearing of both the author and the book (which probably says more about me), and it seems kind of odd that the definition differs from what is usually taught in class (at least mine). Of course, it wouldn't be the first time that popular u…

I don't know what else to do but appeal to authority - it's the definition of a word after all?

https://cs.illinois.edu/about/people/faculty/padua

> David Padua has served as program committee member, program chair, or general chair to more than 70 conferences and workshops. He was the Editor-in-Chief of Springer‐Verlag’s Encyclopedia of Parallel Computing and is currently a member of the editorial board of the Communications of the ACM, the Journal of Parallel and Distributed Computing, and the International Journal of Parallel Programming.

Re: Race Conditions Can Be Useful for Parallelism

#68

Post by raphlinus »

mgaunard wrote: post #53
raphlinus wrote: post #49

Earlier quoted context omitted.

The actual rules are very complicated. C allows greater precision for intermediate results but compilers are sometimes careful to stick to IEEE rounding. [1] contains a good general overview, and [2] talks about FMA in particular. And in [3] I've set up a Godbolt example to play with. By default -O3 gives you FMA, but -O or -O3 with -ffp-contract=off don't. So you absolutely can get different results depending on opt…

The rule is very simple, I'm not seeing anything in what you say suggesting that it isn't?

Perhaps the rule in the standard is simple - the compiler can arbitrarily round to finer precision than IEEE, but in practice it's complicated as the same code can behave quite differently depending on what chip it's compiled for, the level of optimizations, and other factors. If you want to control it, ie model it as something other than nondeterminism, figuring out the right combination of compiler flags and so on is tricky.

I'll also point out that fma is relatively new, so it's pretty easy to write code that works fine when compiled with default x86_64/SSE2 but will break when compiled for a more recent target cpu.

Re: Race Conditions Can Be Useful for Parallelism

#69

Post by oconnor663 »

kaba0 wrote: post #45
shwestrick wrote: post #41

Earlier quoted context omitted.

That's a nice example. It seems that data races in Java don't "catch fire"; is that correct? The catch-fire problem is pretty bad for languages like C/C++, which have undefined behavior for data races, and in this sense data races are "bugs by definition" in those languages.

Java’s primitives and references are guaranteed to be “tear-free”, which guarantees no “out-of-thin-air” values. So a field set to 1 and being written by several threads to 2 and 3 can only ever be observed as 1,2 or 3, no other value. Is that what you mean under not catching fire?

I think catching fire here refers to the general "this is UB and all bets are off" situation. For example, if you're data racing against an int on x86-64 Linux, you might reason that the `mov` instruction on that platform can't possibly product torn reads. And you'd be right as far as that goes. But the C/C++/Rust compiler still considers those data races UB and may still do horrible things like just deleting big chunks of your code if it manages to prove that that's what you've done.

Re: Race Conditions Can Be Useful for Parallelism

#70

Post by mgaunard »

raphlinus wrote: post #68
mgaunard wrote: post #53

Earlier quoted context omitted.

The rule is very simple, I'm not seeing anything in what you say suggesting that it isn't?

Perhaps the rule in the standard is simple - the compiler can arbitrarily round to finer precision than IEEE, but in practice it's complicated as the same code can behave quite differently depending on what chip it's compiled for, the level of optimizations, and other factors. If you want to control it, ie model it as something other than nondeterminism, figuring out the right combination of compiler flags and so on…

All you're doing is listing simple consequences of the rule.

The compiler may use increased precision for intermediate computations. That means sometimes it will, sometimes it won't. If you understand the basics of the situations where it will do so, you can see it depends on register allocation, which of course not only depends on optimization level, but also can change anytime you change anything at all in the source code.

Post reply on HN