4 ms·

He’s talking about formal memory models, which are a bit different from what you’re talking about (though you’re correct that they are pragmatically similar.) C

He’s talking about formal memory models, which are a bit different from what you’re talking about (though you’re correct that they are pragmatically similar.) C/C++ has a formalized memory model that describe the high level logical rules/guarantees for writing safe concurrent code, while Unsafe Rust doesn’t have one explicitly written in spec/paper (although they kinda borrowed a less-formalized version of it from C/C++.) It has to do with ironing out hardware-specific behavior to obey a certain set of rules, while making sure all the compiler optimizations do not perform any invalid transformations against these rules. (The Rustonomicon explains this well in layman terms, and acknowledges the complexity of the issue: https://doc.rust-lang.org/nomicon/atomics.html https://doc.rust-lang.org/nomicon/atomics.html) In practice, it seems like the C/C++ model has some glaring flaws anyway, so I can’t say that Rust’s is really “worse”. But since Rust has this mission to be better than C++ in terms of safety, this is one of thorny issues of Rust that need to be tackled to really let its advantages shine.

JonChesterfield 4y ago
I thought the C11 memory model was considered correct, possibly modulo 'consume' which seems to be ignored. The implementation in terms of types instead of operations has a performance cost but otherwise works. What glaring flaws do you have in mind?
- cyber_kinetist 4y ago
  Well, not exactly “glaring” (unless you are a PL expert), but for instance there’s a paper that was referenced in that Rustonomicon link: https://fzn.fr/readings/c11comp.pdf https://fzn.fr/readings/c11comp.pdf And also https://plv.mpi-sws.org/scfix/paper.pdf https://plv.mpi-sws.org/scfix/paper.pdf Though maybe these issues were fixed in C++20 (which I only learned till recently that they’ve revised their memory model there!)
  - JonChesterfield 4y ago
    Nice references. Going to take me a while to make sense of them. A superficial interpretation is one says relaxed doesn't work and the other says sequentially consistent doesn't work. Not great news tbh, hopefully it'll look better on closer examination.

JonChesterfield 4y ago

I thought the C11 memory model was considered correct, possibly modulo 'consume' which seems to be ignored. The implementation in terms of types instead of operations has a performance cost but otherwise works. What glaring flaws do you have in mind?

cyber_kinetist 4y ago
Well, not exactly “glaring” (unless you are a PL expert), but for instance there’s a paper that was referenced in that Rustonomicon link: https://fzn.fr/readings/c11comp.pdf https://fzn.fr/readings/c11comp.pdf And also https://plv.mpi-sws.org/scfix/paper.pdf https://plv.mpi-sws.org/scfix/paper.pdf Though maybe these issues were fixed in C++20 (which I only learned till recently that they’ve revised their memory model there!)
- JonChesterfield 4y ago
  Nice references. Going to take me a while to make sense of them. A superficial interpretation is one says relaxed doesn't work and the other says sequentially consistent doesn't work. Not great news tbh, hopefully it'll look better on closer examination.