3 ms·

Its also important to note that for most systems security critical memory safety is a REALLY big deal, but safety from crashes due to data races is generally no

by pa7ch 5y ago

Its also important to note that for most systems security critical memory safety is a REALLY big deal, but safety from crashes due to data races is generally not a big deal. Rust has trade-offs to accomplish this. We proven time and time again we can't write safe c/c++ code from a security perspective. I don't think we've proven that crashing now and then to fix our data races is a bad outcome. There are always bugs to be fixed.

tialaramex 5y ago
The consequence of a data race isn't (necessarily) limited to "crashing now and then". The big problem is SC/DRF. Most languages promise (at best) your program is sequentially consistent if data race free. And it turns out we can't debug non-trivial programs unless they're sequentially consistent because it hurts our brains too much. Causality is something we're all used to in the real world. The man hits the ball with the bat, then the ball's trajectory changes, because it struck the bat. Sequentially consistent programs are the same. X was five, then we doubled it, now it's ten. But without sequential consistency that's not how your program works at all. The ball goes flying off over the wall around the field, then the pitcher throws the ball, the ball lands in the catcher's glove, the umpire calls it, the batter hits the ball, and yet at the same time misses the ball... We doubled X, now it's five, but before we doubled it that was nine or sixteen? What?
masklinn 5y ago
> Its also important to note that for most systems security critical memory safety is a REALLY big deal, but safety from crashes due to data races is generally not a big deal. It must be noted, though, that data races can lead to memory safety issues in languages which are otherwise free of them, Go being a prime example of that: the built-in hashmap is not thread-safe, and does exhibit memory corruption issues under unprotected concurrent writes and accesses (only concurrent unprotected reads are OK). There is a “best effort detection” of concurrent misuse, but it’s just that.

by pa7ch 5y ago

tialaramex 5y ago

The consequence of a data race isn't (necessarily) limited to "crashing now and then". The big problem is SC/DRF. Most languages promise (at best) your program is sequentially consistent if data race free. And it turns out we can't debug non-trivial programs unless they're sequentially consistent because it hurts our brains too much. Causality is something we're all used to in the real world. The man hits the ball with the bat, then the ball's trajectory changes, because it struck the bat. Sequentially consistent programs are the same. X was five, then we doubled it, now it's ten. But without sequential consistency that's not how your program works at all. The ball goes flying off over the wall around the field, then the pitcher throws the ball, the ball lands in the catcher's glove, the umpire calls it, the batter hits the ball, and yet at the same time misses the ball... We doubled X, now it's five, but before we doubled it that was nine or sixteen? What?

masklinn 5y ago

> Its also important to note that for most systems security critical memory safety is a REALLY big deal, but safety from crashes due to data races is generally not a big deal. It must be noted, though, that data races can lead to memory safety issues in languages which are otherwise free of them, Go being a prime example of that: the built-in hashmap is not thread-safe, and does exhibit memory corruption issues under unprotected concurrent writes and accesses (only concurrent unprotected reads are OK). There is a “best effort detection” of concurrent misuse, but it’s just that.