6 ms·

> You can have perfectly safe Rust code with data races No, you can't. Data races are explicitly one type of race condition that Rust protects you from. Anythi

> You can have perfectly safe Rust code with data races No, you can't. Data races are explicitly one type of race condition that Rust protects you from. Anything else would indicate an unsound library or compiler bug. For reference, you can take a look at the non-exhaustive list of undefined behaviors[0]. None of those behaviours should be possible to trigger from safe Rust. [0] https://doc.rust-lang.org/reference/behavior-considered-undefined.html https://doc.rust-lang.org/reference/behavior-considered-unde...

hu3 2y ago
As per https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html > However Rust does not prevent general race conditions. > This is mathematically impossible in situations where you do not control the scheduler, which is true for the normal OS environment. > For this reason, it is considered "safe" for Rust to get deadlocked or do something nonsensical with incorrect synchronization: this is known as a general race condition or resource race. Obviously such a program isn't very good, but Rust of course cannot prevent all logic errors.
- couchand 2y ago
  On the one hand, we like to encourage learning here. On the other, we prefer not to copy-paste a bunch of possibly-irrelevant content. Well, forgive me for pasting in a StackOverflow answer that may be relevant here: https://stackoverflow.com/questions/11276259/are-data-races-and-race-condition-actually-the-same-thing-in-context-of-conc#18049303 https://stackoverflow.com/questions/11276259/are-data-races-... > Are "data races" and "race condition" actually the same thing in context of concurrent programming > No, they are not the same thing. They are not a subset of one another. They are also neither the necessary, nor the sufficient condition for one another. The really curious thing here is that the Nomicon page also describes this distinction in great detail.
  - hu3 2y ago
    [flagged]
    - couchand 2y ago
      I apologize if my comment came off as snark. Your comment was nothing but pasted text which ommitted relevant detail, so it was not clear what the intent was. In context, to me, it did not seem to be illuminating. It actually seemed to be introducing confusion where there previously was none. Data races are not possible in safe Rust. Race conditions are. The distinction is made clear in the Nomicon article, but commenters here are really muddying the waters...
      - hu3 2y ago
        Clearly there is still confusion since we don't agree (as does other the aforementioned poster). I could have also belittled your comment as "bunch of possibly-irrelevant content" since most of the content was and still is unnecessary snark. But then it would have said more about my own etiquette and capability to debate objectively than about the topic at hand. Our definition of data race seems to differ, and because you don't seem to be able to separate objective discussion from personal attacks, I'll stop here.
        tialaramex 2y ago
        > I could have also belittled your comment as "bunch of possibly-irrelevant content" That doesn't really make sense because there are other witnesses, so everybody who knows about this topic can see immediately that you're wrong and the other person is right.
        hu3 2y ago
        Regardless if technically right or not tialaramex, couchand's messages also contained belittling and snarky content. So one could have written just the same about what they wrote because of what it also contained. "bunch of possibly-irrelevant content". This kind of behavior is not justifiable on technical merits alone. At least it shouldn't be.
Galanwe 2y ago
You can have both data races and race conditions in a perfectly safe Rust program. Rust can only offer its safety for the lifetimes it tracks, and this tracking is limited to a single instance of your process. In other words, if you perform concurrent accesses through multiple threads spawned from a same process, you're safe from data races, at risk of race conditions. If you perform concurrent accesses through multiples processes, you're at risk of both. That implies that even in a world where everything is safe Rust, you cannot guarantee that these two Rust processes will not data races together.
- oconnor663 2y ago
  > If you perform concurrent accesses through multiples processes How would you do that in safe code? If I understand correctly, the problem you're referring to is the exact reason that mmap APIs in Rust are unsafe: https://docs.rs/memmap2/latest/memmap2/struct.Mmap.html#safety https://docs.rs/memmap2/latest/memmap2/struct.Mmap.html#safe...
  - nindalf 2y ago
    I don't agree with the point GP is making, but presumably something like two processes writing a file and reading their changes back. If the writes and reads interleave you'd get a race condition.
    - couchand 2y ago
      That's decidedly not a data race, however.
- bigstrat2003 2y ago
  I don't think most people expect language safety guarantees to extend to other processes. That's a pretty unrealistic expectation you are bringing.
  - Galanwe 2y ago
    I don't think that's unrealistic, it all depends on which sphere of development you're navigating into. In highly concurrent/long lived systems, you often end up using a multiprocess approach between your producers and consumers rather than multithreading. This is because it allows you to dynamically spawn new processes to consume from a shared memory without going through a bastion process managing threaded consumers. e. g. It allows you to spawn at will newly developed consumers without redeploying and restarting the producers. Note that this does not mean a different codebase. As for the expectations, I think it's fair to highlight it. Because people tend to think that a world of applications fully developed in Rust would somehow imply no data races. That's not the case: On a fully fault-free operating system, with only 100% safe Rust applications running, you can, and will, still run into data races, because in the real world applications cross process boundaries.

hu3 2y ago

As per https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html > However Rust does not prevent general race conditions. > This is mathematically impossible in situations where you do not control the scheduler, which is true for the normal OS environment. > For this reason, it is considered "safe" for Rust to get deadlocked or do something nonsensical with incorrect synchronization: this is known as a general race condition or resource race. Obviously such a program isn't very good, but Rust of course cannot prevent all logic errors.

couchand 2y ago
On the one hand, we like to encourage learning here. On the other, we prefer not to copy-paste a bunch of possibly-irrelevant content. Well, forgive me for pasting in a StackOverflow answer that may be relevant here: https://stackoverflow.com/questions/11276259/are-data-races-and-race-condition-actually-the-same-thing-in-context-of-conc#18049303 https://stackoverflow.com/questions/11276259/are-data-races-... > Are "data races" and "race condition" actually the same thing in context of concurrent programming > No, they are not the same thing. They are not a subset of one another. They are also neither the necessary, nor the sufficient condition for one another. The really curious thing here is that the Nomicon page also describes this distinction in great detail.
- hu3 2y ago
  [flagged]
  - couchand 2y ago
    I apologize if my comment came off as snark. Your comment was nothing but pasted text which ommitted relevant detail, so it was not clear what the intent was. In context, to me, it did not seem to be illuminating. It actually seemed to be introducing confusion where there previously was none. Data races are not possible in safe Rust. Race conditions are. The distinction is made clear in the Nomicon article, but commenters here are really muddying the waters...
    - hu3 2y ago
      Clearly there is still confusion since we don't agree (as does other the aforementioned poster). I could have also belittled your comment as "bunch of possibly-irrelevant content" since most of the content was and still is unnecessary snark. But then it would have said more about my own etiquette and capability to debate objectively than about the topic at hand. Our definition of data race seems to differ, and because you don't seem to be able to separate objective discussion from personal attacks, I'll stop here.
      - tialaramex 2y ago
        > I could have also belittled your comment as "bunch of possibly-irrelevant content" That doesn't really make sense because there are other witnesses, so everybody who knows about this topic can see immediately that you're wrong and the other person is right.
        hu3 2y ago
        Regardless if technically right or not tialaramex, couchand's messages also contained belittling and snarky content. So one could have written just the same about what they wrote because of what it also contained. "bunch of possibly-irrelevant content". This kind of behavior is not justifiable on technical merits alone. At least it shouldn't be.

Galanwe 2y ago

You can have both data races and race conditions in a perfectly safe Rust program. Rust can only offer its safety for the lifetimes it tracks, and this tracking is limited to a single instance of your process. In other words, if you perform concurrent accesses through multiple threads spawned from a same process, you're safe from data races, at risk of race conditions. If you perform concurrent accesses through multiples processes, you're at risk of both. That implies that even in a world where everything is safe Rust, you cannot guarantee that these two Rust processes will not data races together.

oconnor663 2y ago
> If you perform concurrent accesses through multiples processes How would you do that in safe code? If I understand correctly, the problem you're referring to is the exact reason that mmap APIs in Rust are unsafe: https://docs.rs/memmap2/latest/memmap2/struct.Mmap.html#safety https://docs.rs/memmap2/latest/memmap2/struct.Mmap.html#safe...
- nindalf 2y ago
  I don't agree with the point GP is making, but presumably something like two processes writing a file and reading their changes back. If the writes and reads interleave you'd get a race condition.
  - couchand 2y ago
    That's decidedly not a data race, however.
bigstrat2003 2y ago
I don't think most people expect language safety guarantees to extend to other processes. That's a pretty unrealistic expectation you are bringing.
- Galanwe 2y ago
  I don't think that's unrealistic, it all depends on which sphere of development you're navigating into. In highly concurrent/long lived systems, you often end up using a multiprocess approach between your producers and consumers rather than multithreading. This is because it allows you to dynamically spawn new processes to consume from a shared memory without going through a bastion process managing threaded consumers. e. g. It allows you to spawn at will newly developed consumers without redeploying and restarting the producers. Note that this does not mean a different codebase. As for the expectations, I think it's fair to highlight it. Because people tend to think that a world of applications fully developed in Rust would somehow imply no data races. That's not the case: On a fully fault-free operating system, with only 100% safe Rust applications running, you can, and will, still run into data races, because in the real world applications cross process boundaries.