[chrisseaton]

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]

> 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.

[pcwalton]

> 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.

[staticassertion]

> 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.