4 ms·
Can you elaborate on that?
by ferreiratb 1y ago
Can you elaborate on that?
- wpollock 1y agoA Java program can share mutable state between threads without synchronization, and it will compile and run. In Rust, such a program will not compile.
- int_19h 1y agoYes, but even so you will never see e.g. an invalid pointer value as the result of a torn memory write. Basically, no matter what you do with threads in Java, it will not segfault. TFA's point is that (safe) Rust is also like that, but achieves it by restricting all cases where a torn write could be observed through its type system instead of VM's memory model.
- dontlaugh 1y agoMore specifically, Rust prevents data races.
- BlackFly 1y agoNo, rust forces you to use a mutex but nothing will prevent you from making the mutex too small and creating tearing in your own data structures by sequentially modifying things covered by mutexes so that in between acquisition of the locks you are violating invariants. The borrow checker certainly helps however, but not without cost that was finally minimized when the scoped threads api came along. Java has a very specific memory model, so the behavior of variables across threads is quite well defined. Basic variables can tear however (a 64bit long on a 32bit architecture) without the volatile keyword and that is quite different than rust.
- dontlaugh 1y agoYou didn’t describe any data races. What Rust prevents is very specific.
- int_19h 1y agoOP described situations where you get observable invariant violations because of torn non-atomic writes. This is basically any case involving e.g. copying of variables that are larger than whatever's atomic for a given architecture. Say, a struct of 4 isize.