3 ms·

I’m but a mere mortal but as an outside observer of rust and from my playing around with it, doesn’t the borrow checker currently handle this for you? Ie part o

by mlazos 5y ago

I’m but a mere mortal but as an outside observer of rust and from my playing around with it, doesn’t the borrow checker currently handle this for you? Ie part of fearless concurrency?

pcwalton 5y ago
The lifetimes and borrow check make sure that, no matter what order your threads execute in, nothing bad (memory-unsafe) will ever happen. But it doesn't say anything about what that order is. That's what a memory model is for. (This is handwavy and imprecise, but it's the easiest way I can explain it.)
- masklinn 5y ago
  I agree, the “fearlessness” is that you can’t share things which must not be shared (e.g. unprotected writables). And there are a fair amount of quite ergonomic constructs to manage concurrency. However if you start manipulating atomics directly, while the atomics themselves are safe the behaviour can get quite complicated below seqcst. The latest Crust of Rust is rather illuminating to the subject for people like me who had not had to really dive into the logic and implications.
- gpderetta 5y ago
  That's very interesting. I would have intuitively expected that memory reordering could have been used to subvert memory safety. Can you point me to more discussion on the topic?
  - exDM69 5y ago
    Atomics and mutexes constrain memory reordering. Stores and loads while holding a mutex can't be reordered so that they happen outside the mutex lock (because there are compiler/cpu memory barriers in mutex lock/unlock). Given that Rust's "shared xor mutable" is guarded with mutexes, atomics or other synchronization primitives, memory reordering can't violate Rust's memory safety guarantees (assuming the sync primitives are not buggy, of course). But this does not guarantee that your program logic is correct if you are sloppy with memory ordering. If you do two atomic stores, they are not guaranteed to occur in that order if they use "relaxed" ordering. This gets more complex if you're writing device drivers and communicating with peripheral devices using memory mapped i/o.
    - gpderetta 5y ago
      But atomicptr can be used with relaxed constraints, so in principle a consumer can see the pointed object before it was initialized. I think rust gets away because atomic ptr is a raw ptr so it can only be dereferenced in unsafe code. So in practice relaxed atomics require unsafe where it matter (which makes sense to me).
kelnos 5y ago
Rust will ensure that you don't have any undefined behavior or use-after-free when you write a concurrent program. The memory model is something different: it governs how memory operations are ordered in a concurrent system. You can have a program with no memory safety issues, but nonetheless is not correct (that is, it doesn't do what you expect it to do) because you have specified the wrong memory ordering of some operations.

by mlazos 5y ago

I’m but a mere mortal but as an outside observer of rust and from my playing around with it, doesn’t the borrow checker currently handle this for you? Ie part of fearless concurrency?

pcwalton 5y ago

The lifetimes and borrow check make sure that, no matter what order your threads execute in, nothing bad (memory-unsafe) will ever happen. But it doesn't say anything about what that order is. That's what a memory model is for. (This is handwavy and imprecise, but it's the easiest way I can explain it.)

masklinn 5y ago
I agree, the “fearlessness” is that you can’t share things which must not be shared (e.g. unprotected writables). And there are a fair amount of quite ergonomic constructs to manage concurrency. However if you start manipulating atomics directly, while the atomics themselves are safe the behaviour can get quite complicated below seqcst. The latest Crust of Rust is rather illuminating to the subject for people like me who had not had to really dive into the logic and implications.
gpderetta 5y ago
That's very interesting. I would have intuitively expected that memory reordering could have been used to subvert memory safety. Can you point me to more discussion on the topic?
- exDM69 5y ago
  Atomics and mutexes constrain memory reordering. Stores and loads while holding a mutex can't be reordered so that they happen outside the mutex lock (because there are compiler/cpu memory barriers in mutex lock/unlock). Given that Rust's "shared xor mutable" is guarded with mutexes, atomics or other synchronization primitives, memory reordering can't violate Rust's memory safety guarantees (assuming the sync primitives are not buggy, of course). But this does not guarantee that your program logic is correct if you are sloppy with memory ordering. If you do two atomic stores, they are not guaranteed to occur in that order if they use "relaxed" ordering. This gets more complex if you're writing device drivers and communicating with peripheral devices using memory mapped i/o.
  - gpderetta 5y ago
    But atomicptr can be used with relaxed constraints, so in principle a consumer can see the pointed object before it was initialized. I think rust gets away because atomic ptr is a raw ptr so it can only be dereferenced in unsafe code. So in practice relaxed atomics require unsafe where it matter (which makes sense to me).

kelnos 5y ago

Rust will ensure that you don't have any undefined behavior or use-after-free when you write a concurrent program. The memory model is something different: it governs how memory operations are ordered in a concurrent system. You can have a program with no memory safety issues, but nonetheless is not correct (that is, it doesn't do what you expect it to do) because you have specified the wrong memory ordering of some operations.