6 ms·

How Rust Achieves Thread Safety

88 points by nxnfufunezn 11y ago

Animats 11y ago
That's a good subject. This Rust blog entry[1] is perhaps a better explanation. When you pass data to another thread, there are three options: 1) pass a copy, 2) hand off ownership to the other thread, and 3) transfer ownership to a mutex object, then borrow it from the mutex object as needed. All of these are memory and race condition safe due to compile time checking. Those are the concepts. The Rust syntax needed to support it is somewhat complicated, but if you get it wrong, you get compile time error messages. This may be the biggest advance in software concurrency management since Dijkstra's P and V. Almost everything in wide use is either P and V under a different name, or some subset of P and V functionality. Locks are not a basic part of most languages; the language doesn't know what a lock is locking. The Ada rendezvous and Java synchronized objects are exceptions. Those were good ideas, but too restrictive. Finally, we're past that. Go could have worked this way. Go originally claimed to be concurrency safe, but it's not. You can pass a reference across a channel, and now you're sharing an unlocked data object. This is easy to do by accident, because slices are references. Because Go is garbage collected, it's almost memory safe (there's a race condition around slice descriptors that can be exploited), but it doesn't protect the program's data against shared access. In Rust, when you pass an non-copyable object across a channel, the sender gives up the right to use it, and the compiler enforces that. [1] http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...
- detrino 11y ago
  That's not true, Rust permits opt-in data races in safe code.
  - dbaupp 11y ago
    If what you say is true, it's a bug: there should only be a risk of data races if `unsafe` is used. Do you have a code example?
    - veddan 11y ago
      I'm guessing he refers to atomics with relaxed memory ordering. That doesn't give much in terms of guarantees beyond atomicity and no "out-of-thin-air" values. I'm not sure of whether this is a data race under Rust's definition though.
      - detrino 11y ago
        Rust doesn't get to redefine "data race".
        pcwalton 11y ago
        It doesn't. We use the same definition of "data race" as tools like Thread Sanitizer and Eraser do.
        detrino 11y ago
        From tsan documentation: "A data race occurs when two threads access the same variable concurrently and at least one of the accesses is write"
        pcwalton 11y ago
        That's right, and Rust bans that. The definition of "concurrently" typically means "without synchronization in between". An atomic access is by definition a form of synchronization.
        detrino 11y ago
        Relaxed access of atomics performs no synchronization.
        Gankro 11y ago
        It guarantees that the value read was some value that was in the variable at some point. e.g. it prevents a value that toggles from 3 to 5 being read as 117. It also prevents writes from being eaten (e.g. an increment always actually occurs). This necessitates some level of synchronization.
  - deleted 11y ago
    [deleted]
- Manishearth 11y ago
  (Note: The Rust blog post is more about how to use Rust's concurrency safety, mine focuses on the design and how it builds up to create a great system) > This may be the biggest advance in software concurrency management since Dijkstra's P and V. +1 . I'm not sure whose idea it was, but the idea behind the Send/Sync traits is brilliant. It's easy to say "we can mark a type as thread safe and non threadsafe". It takes some thought to come up with a design which works in a world of data sharing. Someone realized that thread safety was actually two, intertwined and interdependent concepts -- thread safe and share-safe[^1], and together they allowed for a good degree of safety without being too restrictive (unlike just having "non threadsafe" types). [^1]: I am greatly oversimplifying the situation by calling them these names, but .. for a less simplified characterization, read the post :P
- dbaupp 11y ago
  > When you pass data to another thread, there are three options: 1) pass a copy, 2) hand off ownership to the other thread, and 3) transfer ownership to a mutex object, then borrow it from the mutex object as needed. All of these are memory and race condition safe due to compile time checking. There's more than those three: data can be shared via reference or reference counted pointers[Arc], which allows immutable access (more generally, concurrent access to any types for which this is safe, e.g. atomics and mutexes). A mutex is only necessary for mutating (nearly) arbitrary shared data. This is particularly powerful for literally zero-overhead read-only shared memory while still maintaining Rust's safety guarantees. [Arc]: http://doc.rust-lang.org/std/sync/struct.Arc.html http://doc.rust-lang.org/std/sync/struct.Arc.html

88 points by nxnfufunezn 11y ago

That's a good subject. This Rust blog entry[1] is perhaps a better explanation. When you pass data to another thread, there are three options: 1) pass a copy, 2) hand off ownership to the other thread, and 3) transfer ownership to a mutex object, then borrow it from the mutex object as needed. All of these are memory and race condition safe due to compile time checking. Those are the concepts. The Rust syntax needed to support it is somewhat complicated, but if you get it wrong, you get compile time error messages. This may be the biggest advance in software concurrency management since Dijkstra's P and V. Almost everything in wide use is either P and V under a different name, or some subset of P and V functionality. Locks are not a basic part of most languages; the language doesn't know what a lock is locking. The Ada rendezvous and Java synchronized objects are exceptions. Those were good ideas, but too restrictive. Finally, we're past that. Go could have worked this way. Go originally claimed to be concurrency safe, but it's not. You can pass a reference across a channel, and now you're sharing an unlocked data object. This is easy to do by accident, because slices are references. Because Go is garbage collected, it's almost memory safe (there's a race condition around slice descriptors that can be exploited), but it doesn't protect the program's data against shared access. In Rust, when you pass an non-copyable object across a channel, the sender gives up the right to use it, and the compiler enforces that. [1] http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

detrino 11y ago
That's not true, Rust permits opt-in data races in safe code.
- dbaupp 11y ago
  If what you say is true, it's a bug: there should only be a risk of data races if `unsafe` is used. Do you have a code example?
  - veddan 11y ago
    I'm guessing he refers to atomics with relaxed memory ordering. That doesn't give much in terms of guarantees beyond atomicity and no "out-of-thin-air" values. I'm not sure of whether this is a data race under Rust's definition though.
    - detrino 11y ago
      Rust doesn't get to redefine "data race".
      - pcwalton 11y ago
        It doesn't. We use the same definition of "data race" as tools like Thread Sanitizer and Eraser do.
        detrino 11y ago
        From tsan documentation: "A data race occurs when two threads access the same variable concurrently and at least one of the accesses is write"
        pcwalton 11y ago
        That's right, and Rust bans that. The definition of "concurrently" typically means "without synchronization in between". An atomic access is by definition a form of synchronization.
        detrino 11y ago
        Relaxed access of atomics performs no synchronization.
        Gankro 11y ago
        It guarantees that the value read was some value that was in the variable at some point. e.g. it prevents a value that toggles from 3 to 5 being read as 117. It also prevents writes from being eaten (e.g. an increment always actually occurs). This necessitates some level of synchronization.
- deleted 11y ago
  [deleted]
Manishearth 11y ago
(Note: The Rust blog post is more about how to use Rust's concurrency safety, mine focuses on the design and how it builds up to create a great system) > This may be the biggest advance in software concurrency management since Dijkstra's P and V. +1 . I'm not sure whose idea it was, but the idea behind the Send/Sync traits is brilliant. It's easy to say "we can mark a type as thread safe and non threadsafe". It takes some thought to come up with a design which works in a world of data sharing. Someone realized that thread safety was actually two, intertwined and interdependent concepts -- thread safe and share-safe[^1], and together they allowed for a good degree of safety without being too restrictive (unlike just having "non threadsafe" types). [^1]: I am greatly oversimplifying the situation by calling them these names, but .. for a less simplified characterization, read the post :P
dbaupp 11y ago
> When you pass data to another thread, there are three options: 1) pass a copy, 2) hand off ownership to the other thread, and 3) transfer ownership to a mutex object, then borrow it from the mutex object as needed. All of these are memory and race condition safe due to compile time checking. There's more than those three: data can be shared via reference or reference counted pointers[Arc], which allows immutable access (more generally, concurrent access to any types for which this is safe, e.g. atomics and mutexes). A mutex is only necessary for mutating (nearly) arbitrary shared data. This is particularly powerful for literally zero-overhead read-only shared memory while still maintaining Rust's safety guarantees. [Arc]: http://doc.rust-lang.org/std/sync/struct.Arc.html http://doc.rust-lang.org/std/sync/struct.Arc.html