4 ms·

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 trackin

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.
  - steveklabnik 2y ago
    What is your definition of "data race"? While I'm aware of some differences in opinion in the details, all of the definitions I'm aware of exclusively refer to multiple threads of execution writing to the same memory location, which makes the concept of a multi-process data race impossible. For example, Regehr: https://blog.regehr.org/archives/490 https://blog.regehr.org/archives/490 A data race happens when there are two memory accesses in a program where both: target the same location are performed concurrently by two threads are not reads are not synchronization operations
    - Galanwe 2y ago
      The subtle differences (or lack of) between threads and processes don't really matter IMHO. A data race happen when two concurrent accesses on the same memory location happen, one of these accesses is a write, and there is no (correct) synchronization in place. The means by which this memory location was shared don't really matter. Whether it was because both processes share the same initial memory space, or whether this memory space was mapped later on, or even whether both accesses were from a mapped space, is really not of the matter. You could have two threads mmap the same shared memory to communicate for what it matters.

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.
- steveklabnik 2y ago
  What is your definition of "data race"? While I'm aware of some differences in opinion in the details, all of the definitions I'm aware of exclusively refer to multiple threads of execution writing to the same memory location, which makes the concept of a multi-process data race impossible. For example, Regehr: https://blog.regehr.org/archives/490 https://blog.regehr.org/archives/490 A data race happens when there are two memory accesses in a program where both: target the same location are performed concurrently by two threads are not reads are not synchronization operations
  - Galanwe 2y ago
    The subtle differences (or lack of) between threads and processes don't really matter IMHO. A data race happen when two concurrent accesses on the same memory location happen, one of these accesses is a write, and there is no (correct) synchronization in place. The means by which this memory location was shared don't really matter. Whether it was because both processes share the same initial memory space, or whether this memory space was mapped later on, or even whether both accesses were from a mapped space, is really not of the matter. You could have two threads mmap the same shared memory to communicate for what it matters.