4 ms·

"The Rust compiler normally disallows any code with race conditions" Lol what? Unless tasks cannot communicate at all, or they are scheduled entirely determini

"The Rust compiler normally disallows any code with race conditions" Lol what? Unless tasks cannot communicate at all, or they are scheduled entirely deterministically, how can the compiler eliminate race conditions? How can a compiler even determine what is a race conditions and what is intended non-determinstic behaviour.

pcwalton 13y ago
Usually we say data races to be clear. Rust has full support for shared memory, but the compiler ensures that you are not accessing it without locking if it's mutable. (If the memory is immutable you can access it without a lock.) You can of course have races in message passing, or the disk, or the network, etc.
- johnhamlet 13y ago
  ...but you can still have races with locking. Data races don't mean data corruption. It simply means the result is dependent on the scheduler or something else out of your control. Two threads set a shared variable to different values. They both lock it before the set it. But that's still a data race, as which thread write first is dependent on the scheduler.
  - dbaupp 13y ago
    No compiler can reason about whether some high-level piece of code is semantically order-of-execution dependent or not; not every non-deterministic piece of code is a race-condition.
    - johnhamlet 13y ago
      You: "not every non-deterministic piece of code is a race-condition" Wikipedia: "A race condition ... is ... where the output is dependent on the sequence or timing..." Boom! Headshot!
      - dbaupp 13y ago
        Being nondeterministic doesn't necessarily meant the output differs. (E.g. a program that increments a global counter (with a lock) once from each of ten threads and prints the count after all threads are finished; the increments happen in a nondeterministic order but the output is always 10.)
      - tinco 13y ago
        The wikipedia article means the sequence or timing of the execution of the instructions in relation to each other. Non-deterministic code does not only encompass code of which the results vary with the timing of instructions relative to each other, but also code of which the results vary with the timing of instructions relative to the state of the universe or anything in it.
      - noahl 13y ago
        Boom! Headshot! That adds nothing to the discussion and makes it feel more adversarial. It reduces the quality of discussion for no gain. Please don't do that again.
  - pcwalton 13y ago
    I'm defining "data race" in the same way that race detectors do—concurrent access to a piece of memory without use of a synchronization primitive. Rust rules those out at compile time.
  - jerf 13y ago
    What exactly is your goal here, with this reply chain you're making? No, Rust has no magical solutions to message passing order. There aren't any, because your "message A" and "message B" could well be network transactions, which will come at you in arbitrary order from two different machines. Given that there's no "solution" to this problem anyhow, what's the point of trying to attack Rust here?
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 ago
  Two 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 ago

pcwalton 13y ago

Usually we say data races to be clear. Rust has full support for shared memory, but the compiler ensures that you are not accessing it without locking if it's mutable. (If the memory is immutable you can access it without a lock.) You can of course have races in message passing, or the disk, or the network, etc.

johnhamlet 13y ago
...but you can still have races with locking. Data races don't mean data corruption. It simply means the result is dependent on the scheduler or something else out of your control. Two threads set a shared variable to different values. They both lock it before the set it. But that's still a data race, as which thread write first is dependent on the scheduler.
- dbaupp 13y ago
  No compiler can reason about whether some high-level piece of code is semantically order-of-execution dependent or not; not every non-deterministic piece of code is a race-condition.
  - johnhamlet 13y ago
    You: "not every non-deterministic piece of code is a race-condition" Wikipedia: "A race condition ... is ... where the output is dependent on the sequence or timing..." Boom! Headshot!
    - dbaupp 13y ago
      Being nondeterministic doesn't necessarily meant the output differs. (E.g. a program that increments a global counter (with a lock) once from each of ten threads and prints the count after all threads are finished; the increments happen in a nondeterministic order but the output is always 10.)
    - tinco 13y ago
      The wikipedia article means the sequence or timing of the execution of the instructions in relation to each other. Non-deterministic code does not only encompass code of which the results vary with the timing of instructions relative to each other, but also code of which the results vary with the timing of instructions relative to the state of the universe or anything in it.
    - noahl 13y ago
      Boom! Headshot! That adds nothing to the discussion and makes it feel more adversarial. It reduces the quality of discussion for no gain. Please don't do that again.
- pcwalton 13y ago
  I'm defining "data race" in the same way that race detectors do—concurrent access to a piece of memory without use of a synchronization primitive. Rust rules those out at compile time.
- jerf 13y ago
  What exactly is your goal here, with this reply chain you're making? No, Rust has no magical solutions to message passing order. There aren't any, because your "message A" and "message B" could well be network transactions, which will come at you in arbitrary order from two different machines. Given that there's no "solution" to this problem anyhow, what's the point of trying to attack Rust here?

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 ago
Two 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 ago