3 ms·

Have i told you about our lord and savior Rust? Anyways, https://github.com/tokio-rs/loom https://github.com/tokio-rs/loom is used by any serious library doing

by Azsy 5y ago

Have i told you about our lord and savior Rust? Anyways, https://github.com/tokio-rs/loom https://github.com/tokio-rs/loom is used by any serious library doing atomic ops/synchronization and it blew me away with how fast it can catch most bugs like this.

nyanpasu64 5y ago
Rust doesn't catch memory ordering errors, which can result in behavioral bugs in safe Rust and data races and memory unsafety in unsafe Rust. But Loom is an excellent tool for catching ordering errors, though its UnsafeCell API differs from std's (and worse yet, some people report Loom returns false positives/negatives in some cases: https://github.com/tokio-rs/loom/issues/180 https://github.com/tokio-rs/loom/issues/180, possibly https://github.com/tokio-rs/loom/issues/166 https://github.com/tokio-rs/loom/issues/166).
- Fiahil 5y ago
  I think it's fixable, the main reactor is what matters. You can add or remove as many synchronisation primitive as you like. Other tooling, like Jepsen, will interact with your program at a higher level.
- CodesInChaos 5y ago
  It doesn't catch all of them. But data-races on plain memory access are impossible in safe rust. And atomics force you to specify an ordering on every access, which helps both the writer (forced to think about which ordering they need) and reviewer (by communicating intent).
- tialaramex 5y ago
  > which can result in behavioral bugs in safe Rust For example, Rust doesn't have any way to know that your chosen lock-free algorithm relies on Acquire-release semantics to perform as intended, and so if you write safe Rust to implement it with Relaxed ordering, it will compile, and run, and on x86-64 it will even work just fine because the cheap behaviour on x86-64 has Acquire-release semantics anyway. But on ARM your program doesn't work because ARM really does have a Relaxed mode and without Acquire-release what you've got is not the clever lock-free algorithm you intended after all. However, if you don't even understand what Ordering is, and just try to implement the naive algorithm in Rust without Atomic operations that take an Ordering, Rust won't compile your program at all because it could race. So this way you are at least confronted with the fact that it's time to learn about Ordering if you want to implement this algorithm and if you pick Relaxed you can keep the resulting (safe) mess you made.

by Azsy 5y ago

nyanpasu64 5y ago

Rust doesn't catch memory ordering errors, which can result in behavioral bugs in safe Rust and data races and memory unsafety in unsafe Rust. But Loom is an excellent tool for catching ordering errors, though its UnsafeCell API differs from std's (and worse yet, some people report Loom returns false positives/negatives in some cases: https://github.com/tokio-rs/loom/issues/180 https://github.com/tokio-rs/loom/issues/180, possibly https://github.com/tokio-rs/loom/issues/166 https://github.com/tokio-rs/loom/issues/166).

Fiahil 5y ago
I think it's fixable, the main reactor is what matters. You can add or remove as many synchronisation primitive as you like. Other tooling, like Jepsen, will interact with your program at a higher level.
CodesInChaos 5y ago
It doesn't catch all of them. But data-races on plain memory access are impossible in safe rust. And atomics force you to specify an ordering on every access, which helps both the writer (forced to think about which ordering they need) and reviewer (by communicating intent).
tialaramex 5y ago
> which can result in behavioral bugs in safe Rust For example, Rust doesn't have any way to know that your chosen lock-free algorithm relies on Acquire-release semantics to perform as intended, and so if you write safe Rust to implement it with Relaxed ordering, it will compile, and run, and on x86-64 it will even work just fine because the cheap behaviour on x86-64 has Acquire-release semantics anyway. But on ARM your program doesn't work because ARM really does have a Relaxed mode and without Acquire-release what you've got is not the clever lock-free algorithm you intended after all. However, if you don't even understand what Ordering is, and just try to implement the naive algorithm in Rust without Atomic operations that take an Ordering, Rust won't compile your program at all because it could race. So this way you are at least confronted with the fact that it's time to learn about Ordering if you want to implement this algorithm and if you pick Relaxed you can keep the resulting (safe) mess you made.