5 ms·

Does Rust and it's borrow checker make this easier/implicit? If compiled code will have to work on both RISC and CISC for the near future. Is the burden to do

Does Rust and it's borrow checker make this easier/implicit? If compiled code will have to work on both RISC and CISC for the near future. Is the burden to do lock free C++ by identifying all the memory conditions outway the learning curve of Rust? Don't know Rust beyond dead simple projects but just curious.

chrismorgan 6y ago
Rust’s ownership and concurrency model prevent you from writing such broken code by accident. The early code examples in the article wouldn’t compile in Rust: you have to use atomic types explicitly, or pass values around explicitly (which will most commonly match the two paradigms of memory sharing and message passing). Rust makes doing things the way shown here quite difficult, which is a good thing, because the idiomatic functionally-equivalent code in Rust will be much easier to follow.
aliceryhl 6y ago
Writing to an ordinary integer in Rust only compiles if it is guaranteed that the integer is not shared with any other code, so writing to that boolean would not compile with an ordinary integer. Rust instead has various special types, such as AtomicBool, that works in the same way as the C++ atomic bool from the example. That said, to actually write the release/acquire thing they did, you will need unsafe code because, to the compiler, the other variables are also shared, and would normally be prevented even if you used the atomic. That said, it would be possible to encapsulate this unsafe in a library without infecting other parts of the code.
mhh__ 6y ago
Compiler checking of multi-threaded code is a good step forward (D has it too, albeit no one's entirely sure how to move forward with the feature), but to access the actual gadget (fence, etc.) you still need some level of either programmer guidance or library code to manage that access
ncmncm 6y ago
You can do everything you might do in Rust equally as easily in C++. The compiler won't hold your hand, so much, but if you wrap the semantics in a library, and use the library, you get the same reliability from it. (This is an unpopular observation in certain places.)
- floatboth 6y ago
  The power of Rust is not in what you can do, it's in what you can't (without the `unsafe` keyword). C++ doesn't have the prevention. If you're not an expert on concurrency, you might just share mutable access to a regular bool variable between threads and use it in that way (as in the article) and nothing would tell you it's wrong. You wouldn't know you need a specific library (or just "to use std::atomic" in this case) until you encounter the weird runtime behavior, try to debug it, try to formulate a google query that describes the bugs/code well enough, and find the answers. "Hand holding" (i.e. rejecting programs that don't conform to more advanced correctness rules) is great. It's what computers are good at. It's foolish not to use computers for this!
  - ncmncm 6y ago
    > C++ doesn't have the prevention Obviously. But that was not the topic. A discipline of single-writer is as easily composed in C++, and, encapsulated in a library, as easily maintained. Nothing about Rust makes this unavailable in C++. The library itself, then, becomes responsible for maintaining the discipline, not the compiler. But once encoded there, it is done. Rust's compiler provides safety advantages, but there is no need to exaggerate them. (Exaggeration is a liability to your language community.)
- adwn 6y ago
  > [...] if you wrap the semantics in a library, and use the library, you get the same reliability from it. Wrong. Rust offers more tools for checking that your library is used correctly than C++ does. First and foremost, the borrow checker – there is nothing comparable in C++, and it's a lot harder/impossible to statically prevent code from modifying shared data after a mutex has been unlocked, for example. > (This is an unpopular observation in certain places.) It is unpopular because it is factually incorrect.

chrismorgan 6y ago

Rust’s ownership and concurrency model prevent you from writing such broken code by accident. The early code examples in the article wouldn’t compile in Rust: you have to use atomic types explicitly, or pass values around explicitly (which will most commonly match the two paradigms of memory sharing and message passing). Rust makes doing things the way shown here quite difficult, which is a good thing, because the idiomatic functionally-equivalent code in Rust will be much easier to follow.

aliceryhl 6y ago

Writing to an ordinary integer in Rust only compiles if it is guaranteed that the integer is not shared with any other code, so writing to that boolean would not compile with an ordinary integer. Rust instead has various special types, such as AtomicBool, that works in the same way as the C++ atomic bool from the example. That said, to actually write the release/acquire thing they did, you will need unsafe code because, to the compiler, the other variables are also shared, and would normally be prevented even if you used the atomic. That said, it would be possible to encapsulate this unsafe in a library without infecting other parts of the code.

mhh__ 6y ago

Compiler checking of multi-threaded code is a good step forward (D has it too, albeit no one's entirely sure how to move forward with the feature), but to access the actual gadget (fence, etc.) you still need some level of either programmer guidance or library code to manage that access

ncmncm 6y ago

You can do everything you might do in Rust equally as easily in C++. The compiler won't hold your hand, so much, but if you wrap the semantics in a library, and use the library, you get the same reliability from it. (This is an unpopular observation in certain places.)

floatboth 6y ago
The power of Rust is not in what you can do, it's in what you can't (without the `unsafe` keyword). C++ doesn't have the prevention. If you're not an expert on concurrency, you might just share mutable access to a regular bool variable between threads and use it in that way (as in the article) and nothing would tell you it's wrong. You wouldn't know you need a specific library (or just "to use std::atomic" in this case) until you encounter the weird runtime behavior, try to debug it, try to formulate a google query that describes the bugs/code well enough, and find the answers. "Hand holding" (i.e. rejecting programs that don't conform to more advanced correctness rules) is great. It's what computers are good at. It's foolish not to use computers for this!
- ncmncm 6y ago
  > C++ doesn't have the prevention Obviously. But that was not the topic. A discipline of single-writer is as easily composed in C++, and, encapsulated in a library, as easily maintained. Nothing about Rust makes this unavailable in C++. The library itself, then, becomes responsible for maintaining the discipline, not the compiler. But once encoded there, it is done. Rust's compiler provides safety advantages, but there is no need to exaggerate them. (Exaggeration is a liability to your language community.)
adwn 6y ago
> [...] if you wrap the semantics in a library, and use the library, you get the same reliability from it. Wrong. Rust offers more tools for checking that your library is used correctly than C++ does. First and foremost, the borrow checker – there is nothing comparable in C++, and it's a lot harder/impossible to statically prevent code from modifying shared data after a mutex has been unlocked, for example. > (This is an unpopular observation in certain places.) It is unpopular because it is factually incorrect.