3 ms·
The "default" communication primitive is message passing; and Rust has linear types, so passing anything from one task to another will disallow the use of that
by dbaupp 13y ago
The "default" communication primitive is message passing; and Rust has linear types, so passing anything from one task to another will disallow the use of that thing in the first task. e.g.
let value = something();
channel.send(value);
// I can no longer use `value` here, it was moved into the .send call
(There is some subtlety here; some values don't move when passed around by value, like primitive numeric types, but in general, anything that could cause a race condition (i.e. pointers) moves.)
However, this isn't the end of the concurrency story; as mentioned in that article there is the `unsafe {}` escape hatch which lets you do things that could cause crashes/race conditions/etc. that the compiler wouldn't normally allow (`unsafe` is basically the programmer saying "trust me, I know what I'm doing" to the compiler).
This unsafe hatch allows one to implement shared memory with safe wrappers[1], Arc (Atomic Reference Counted) for immutable shared memory (without any locks[2]) and RWArc and MutexArc for lock-protected mutable shared memory.
[1]: http://static.rust-lang.org/doc/master/extra/arc/index.html http://static.rust-lang.org/doc/master/extra/arc/index.html
[2]: Rust has very good immutability support, so it can express "this value can never be modified" in the type system, so we can have shared memory without locks entirely safely, because we know that there is no modification possible and so no race conditions possible.
(I'm answering the data races question, which may be a non-sequitur if you're asking about race conditions in general, as pcwalton points out.)
- johnhamlet 13y agoTwo tasks A and B both send a message to task C. Does the message from A or the message from B get received by task C first? That's a race condition. "A race condition or race hazard is the behavior of an electronic or software system where the output is dependent on the sequence or timing of other uncontrollable events." "It becomes a bug when events do not happen in the order the programmer intended." http://en.wikipedia.org/wiki/Race_condition http://en.wikipedia.org/wiki/Race_condition If I thought that the message A would definitely get there first - who knows why but that's what I thought when I wrote the code - this is a race condition and a bug. Please explain to me - how does the compiler prevent this race condition and bug?
- dbaupp 13y agoAs I edited in at the bottom of my answer, I slightly misinterpreted what you said and answered the question restricted to data races only.
- pcwalton 13y agoIt doesn't. It prevents data races. (But that said, there was some experimentation a couple of years ago with "channel contracts" in Rust, which allow you to solve that problem in many scenarios by explicitly enumerating the state transitions in your channel. We have the mechanisms still in place to do this as a library if we want to.)
- steveklabnik 13y agoFrom your link: C++11 introduced formal support for multithreading, and defined a data race strictly as a race condition between non-atomic variables. While race conditions in general will continue to exist, a "data race" must be avoided by the programmer, who must assure that only one thread at a time may access any variable if the access is for writing.
- johnhamlet 13y agoWhat does C++11's definitions have to do with anything? This is Rust.
- lucian1900 13y agoI believe the correct term would be "data race", which is a subset of race conditions. If you have no unsafe blocks, it's impossible to race on memory. Races related to messages are of course possible.