3 ms·

One of Rust's strongest features is its ability to outlaw data races. In this case, the 128-bit types only provide mutations that take &mut self, that is, a uni

by dbaupp 10y ago

One of Rust's strongest features is its ability to outlaw data races. In this case, the 128-bit types only provide mutations that take &mut self, that is, a unique unaliased pointer, meaning there's no way to concurrently mutate and hence they are automatically atomic, in a sense.

deleted 10y ago
[deleted]
chrisseaton 10y ago
Does Rust run a memory barrier when ownership is transferred? How does it ensure that the previous owner has finished all its writes when a new owner take over?
- stjepang 10y ago
  To transfer ownership, you would wrap the object in Mutex<T>, send it via Sender<T>, use some other synchronization primitive, or simply pass it over at the moment the thread is spawned. It's up to the synchronization primitives to ensure memory barriers are executed, not the language. So e.g. a Mutex<T> would execute a memory barrier when locking and unlocking. Rust then allows you to pass ownership in a trusted manner only, i.e. through those primitives. Of course, you can also create an unsafe block and say: "Rust, trust me, I know what I'm doing, don't bother me, and these are the invariants I want you to enforce in safe code..." Mutexes are implemented this way.
- dardie 10y ago
  It's built into the type system and checked statically at compile time. In rust, there can only be one 'owner' of a stored value. Ownership can be transferred, borrowed by multiple readers, or borrowed by a single writer. This ensures (at compile time) that there at any given time there is only ever one single writer OR multiple readers. Rust programs are guaranteed to be free of race conditions at compile-time. The above covers the vast majority of situations, but for cases where this is too restrictive their are other language constructs such as reference-counted types.
  - chrisseaton 10y ago
    Right - I get that the compiler ensures it is only accessed by one thread at a time. But what I was asking was at runtime, when ownership transfers how does Rust ensure that writes to the value by the previous owner appear to the new owner before the transfer of ownership appears to the new owner? You can statically guarantee that only one thread owns the object, but you can't statically guarantee the order in which the processor will apply the instructions your compiler generates, without barriers. But the other person answered - you need to ensure that there is an explicit memory barrier yourself when you transfer the object.
    - bretthoerner 10y ago
      > you need to ensure that there is an explicit memory barrier yourself when you transfer the object To add to/clarify this: I don't think you can transfer an object to another thread in safe Rust code without a primitive that will handle the barriers for you. Static ownership tracing doesn't actually know what threads are, because it doesn't even need to.
    - staticassertion 10y ago
      > you need to ensure that there is an explicit memory barrier yourself when you transfer the object. To be clear, you need to write the code yourself, but the compiler won't let you transfer ownership between threads without doing so. There is no way to compile your code without proving to the compiler that you're data race free.
    - pcwalton 10y ago
      > But the other person answered - you need to ensure that there is an explicit memory barrier yourself when you transfer the object. The channels do this.
- Manishearth 10y ago
  All of the standard library primitives that let you view writes from other threads (mutexes and mpsc senders) have memory barriers in them at some point. The language itself doesn't know about memory barriers. It gives you the tools for enforcing thread safety provided your synchronization abstractions have memory barriers in the right place.

by dbaupp 10y ago

deleted 10y ago

[deleted]

chrisseaton 10y ago

Does Rust run a memory barrier when ownership is transferred? How does it ensure that the previous owner has finished all its writes when a new owner take over?

stjepang 10y ago
To transfer ownership, you would wrap the object in Mutex<T>, send it via Sender<T>, use some other synchronization primitive, or simply pass it over at the moment the thread is spawned. It's up to the synchronization primitives to ensure memory barriers are executed, not the language. So e.g. a Mutex<T> would execute a memory barrier when locking and unlocking. Rust then allows you to pass ownership in a trusted manner only, i.e. through those primitives. Of course, you can also create an unsafe block and say: "Rust, trust me, I know what I'm doing, don't bother me, and these are the invariants I want you to enforce in safe code..." Mutexes are implemented this way.
dardie 10y ago
It's built into the type system and checked statically at compile time. In rust, there can only be one 'owner' of a stored value. Ownership can be transferred, borrowed by multiple readers, or borrowed by a single writer. This ensures (at compile time) that there at any given time there is only ever one single writer OR multiple readers. Rust programs are guaranteed to be free of race conditions at compile-time. The above covers the vast majority of situations, but for cases where this is too restrictive their are other language constructs such as reference-counted types.
- chrisseaton 10y ago
  Right - I get that the compiler ensures it is only accessed by one thread at a time. But what I was asking was at runtime, when ownership transfers how does Rust ensure that writes to the value by the previous owner appear to the new owner before the transfer of ownership appears to the new owner? You can statically guarantee that only one thread owns the object, but you can't statically guarantee the order in which the processor will apply the instructions your compiler generates, without barriers. But the other person answered - you need to ensure that there is an explicit memory barrier yourself when you transfer the object.
  - bretthoerner 10y ago
    > you need to ensure that there is an explicit memory barrier yourself when you transfer the object To add to/clarify this: I don't think you can transfer an object to another thread in safe Rust code without a primitive that will handle the barriers for you. Static ownership tracing doesn't actually know what threads are, because it doesn't even need to.
  - staticassertion 10y ago
    > you need to ensure that there is an explicit memory barrier yourself when you transfer the object. To be clear, you need to write the code yourself, but the compiler won't let you transfer ownership between threads without doing so. There is no way to compile your code without proving to the compiler that you're data race free.
  - pcwalton 10y ago
    > But the other person answered - you need to ensure that there is an explicit memory barrier yourself when you transfer the object. The channels do this.
Manishearth 10y ago
All of the standard library primitives that let you view writes from other threads (mutexes and mpsc senders) have memory barriers in them at some point. The language itself doesn't know about memory barriers. It gives you the tools for enforcing thread safety provided your synchronization abstractions have memory barriers in the right place.