4 ms·
> the compiler enforces that you take the locks properly, eliminating data races. I assume you don't mean the compiler prevents deadlocks, but I'd be very happ
by DanWaterworth 13y ago
> the compiler enforces that you take the locks properly, eliminating data races.
I assume you don't mean the compiler prevents deadlocks, but I'd be very happy to be proved wrong.
- kibwen 13y agoHere's a rather old post that describes the kinds of races that the Rust compiler prevents: http://winningraceconditions.blogspot.com/2012/10/what-is-data-race-and-when-is-race-not.html http://winningraceconditions.blogspot.com/2012/10/what-is-da... "[...] Rust's type system guarantees that concurrent tasks cannot share state but instead must use message-passing to communicate, which precludes the possibility of data races completely by enforcing happens-before relationships on all data accesses (or in the case of this post,[1] by enforcing mutual-exclusion relationships). Yet it's still possible to write nondeterministic programs in Rust (using select2, failure propagation, etc), and so race conditions are still possible." ...Though I'm not sure if this is all that pcwalton is referring to. [1] http://winningraceconditions.blogspot.com/2012/09/rust-4-typesafe-shared-mutable-state.html http://winningraceconditions.blogspot.com/2012/09/rust-4-typ...
- pcwalton 13y agoYeah, we don't prevent deadlocks. Stylistically, we try to avoid mutex locks for this reason, but sometimes you need them, so they're there.