5 ms·

Does Rust prevent all mistakes with locking as the post seems to indicate? It prevents the most common issues of accessing variables without mutexes or somethin

Does Rust prevent all mistakes with locking as the post seems to indicate? It prevents the most common issues of accessing variables without mutexes or something incorrectly by requiring them to be wrapped in RwLock or similar, but you can still get deadlocks can you not?

sapiogram 3y ago
Rust does not protect against deadlocks, that is correct. It also doesn't fully prevent mistakes related to ref counting. But I don't get the impression that the post is claiming either of those things?
- pixelesque 3y ago
  Well, maybe that's open to the interpretation of "prevents mistakes" in the text I guess :) I'd argue that "It prevents mistakes with ref counting, locking, bounds checking..." implies "all" mistakes, but hey, maybe not...
  - nextaccountic 3y ago
    Rust-style locks definitely raise the bar, and I wish more languages adopted this - like this https://news.ycombinator.com/item?id=35464152 https://news.ycombinator.com/item?id=35464152 or https://github.com/dragazo/rustex https://github.com/dragazo/rustex
    - masklinn 3y ago
      Yeah just the mutex style (the mutex being a container) even without borrow checker is already progress because it shows the dependency between the lock and the data in the code. The main missing piece in rust locks is inter-lock dependencies when they are not nested.
    - thesuperbigfrog 3y ago
      >> Rust-style locks definitely raise the bar, and I wish more languages adopted this This locking pattern is quite old and frequently available in safe languages. Ada calls it "protected objects" and has had it since Ada 95: https://learn.adacore.com/courses/intro-to-ada/chapters/tasking.html#protected-objects https://learn.adacore.com/courses/intro-to-ada/chapters/task... Java calls it "synchronized" and has had it since Java 5 or 6: https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html https://docs.oracle.com/javase/tutorial/essential/concurrenc...
      - _flux 3y ago
        If I'm not misunderstanding it, those always associate exactly one lock to a exactly one object, which is not what Rust locking is. The Rust (also C++) mechanism is that when you lock a mutex you get a lock guard object and when the scope ends the guard is dropped and therefore the mutex is released; you don't need to put the code accessing the locked data inside a particular locking object. For example, how would one implement https://doc.rust-lang.org/std/sync/struct.RwLock.html https://doc.rust-lang.org/std/sync/struct.RwLock.html with that?
        _flux 3y ago
        I realize that that is actually factually incorrect: you do associate the contents to the locks in Rust, e.g. RwLock<Contents>, though the structure is a bit different as an object doesn't inherently to have a lock. However, you do get to choose what kind of locking scheme you use and, crucially, it is impossible to access said data without holding a lock. Indeed it is not possible to have concurrent access on data without having some locking implemented and used.
      - insanitybit 3y ago
        A difference being that you're safe even without a Mutex at zero cost.
    - loeg 3y ago
      folly::Synchronized provides a similar pattern in C++. I guess it's not widely used outside of Facebook, but it is commonly used inside Facebook FWIW.
  - brookst 3y ago
    Fairly ambiguous. “Prevents some mistakes” would be more clear, but I also don’t read “prevents” as “eliminates the possibility of”.
- galangalalgol 3y ago
  What sorts of errors with ref counting are possible?
  - diarrhea 3y ago
    One guess: memory leaks from circular references. It’s ref counting, and doesn’t do roots checking.
    - galangalalgol 3y ago
      Yeah, you can definitely do that. Typically rust features are trying to prevent undefined behavior, specifically exploitable undefined behavior. In doing so there is low hanging fruit for increasing the likelihood correctness but I don't feel like "correctness at any cost" is its motto. That is more Ada territory. Deadlocks and memory leaks can sometimes be exploited for denial of service, but they are not undefined behavior.
kolektiv 3y ago
You can. There are definitely still footguns - some things are just not easy. But there are also fewer footguns, and the overall type system makes modelling problems in ways which are often simpler to reason about more achievable (trivial example - state machines are common, and easy to represent in relatively safe ways with exhaustively checked enums, matching, etc.) Is rewriting something in Rust a guarantee of no bugs? Nope. But it does likely make it easier for the rewriters to reduce the number of bugs.
- danudey 3y ago
  Also, since Rust provides and enforces the mechanisms to bypass huge swaths of bugs, like many locking errors, concurrency, exhaustive enum checking, etc., that frees up developers to spend their time debugging or reinforcing other areas where Rust can't make similar guarantees of correctness. I recall reading somewhere that a lot of the ideas for Rust's safety system came from a Firefox analysis of bugs that had been reported and fixed, where something like 70% of bugs fell into a few broad categories (mostly memory safety, like use-after-free, buffer overruns, off-by-one, etc) which they could solve in a new language that could enforce correctness. The idea of being able to remove 70% of bugs, and to effectively guarantee that any bugs that do occur happen in those remaining 30% of areas, sounds like it could save a lot of developer time.
pornel 3y ago
All mistakes is such an unachievable high bar, it’s almost a strawman argument. You can always imagine a programmer terrible enough that they will find every possible failure case. However, Rust can prevent quite a lot of common mistakes. Getting rid of UAF, data races, and having deterministic destruction that unlocks locks is already a major quality improvement. Rust can’t prevent deadlocks caused by wrong architecture, but of all concurrency issues deadlocks are the easiest to diagnose.
- imtringued 3y ago
  > You can always imagine a programmer terrible enough that they will find every possible failure case. Uhh, no. That is an amazing programmer! Why? Because truly terrible programmers imagine a subset of every possible failure case and simply refuse to acknowledge other failure cases, especially the ones that are particularly common with particularly severe consequences.
bfrog 3y ago
Rust can prevent races. It cannot guarantee no Deadlocks by itself. However, there are schedulers that do guarantee deadlock free operation written in Rust, see RTIC for example.

sapiogram 3y ago

Rust does not protect against deadlocks, that is correct. It also doesn't fully prevent mistakes related to ref counting. But I don't get the impression that the post is claiming either of those things?

pixelesque 3y ago
Well, maybe that's open to the interpretation of "prevents mistakes" in the text I guess :) I'd argue that "It prevents mistakes with ref counting, locking, bounds checking..." implies "all" mistakes, but hey, maybe not...
- nextaccountic 3y ago
  Rust-style locks definitely raise the bar, and I wish more languages adopted this - like this https://news.ycombinator.com/item?id=35464152 https://news.ycombinator.com/item?id=35464152 or https://github.com/dragazo/rustex https://github.com/dragazo/rustex
  - masklinn 3y ago
    Yeah just the mutex style (the mutex being a container) even without borrow checker is already progress because it shows the dependency between the lock and the data in the code. The main missing piece in rust locks is inter-lock dependencies when they are not nested.
  - thesuperbigfrog 3y ago
    >> Rust-style locks definitely raise the bar, and I wish more languages adopted this This locking pattern is quite old and frequently available in safe languages. Ada calls it "protected objects" and has had it since Ada 95: https://learn.adacore.com/courses/intro-to-ada/chapters/tasking.html#protected-objects https://learn.adacore.com/courses/intro-to-ada/chapters/task... Java calls it "synchronized" and has had it since Java 5 or 6: https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html https://docs.oracle.com/javase/tutorial/essential/concurrenc...
    - _flux 3y ago
      If I'm not misunderstanding it, those always associate exactly one lock to a exactly one object, which is not what Rust locking is. The Rust (also C++) mechanism is that when you lock a mutex you get a lock guard object and when the scope ends the guard is dropped and therefore the mutex is released; you don't need to put the code accessing the locked data inside a particular locking object. For example, how would one implement https://doc.rust-lang.org/std/sync/struct.RwLock.html https://doc.rust-lang.org/std/sync/struct.RwLock.html with that?
      - _flux 3y ago
        I realize that that is actually factually incorrect: you do associate the contents to the locks in Rust, e.g. RwLock<Contents>, though the structure is a bit different as an object doesn't inherently to have a lock. However, you do get to choose what kind of locking scheme you use and, crucially, it is impossible to access said data without holding a lock. Indeed it is not possible to have concurrent access on data without having some locking implemented and used.
    - insanitybit 3y ago
      A difference being that you're safe even without a Mutex at zero cost.
  - loeg 3y ago
    folly::Synchronized provides a similar pattern in C++. I guess it's not widely used outside of Facebook, but it is commonly used inside Facebook FWIW.
- brookst 3y ago
  Fairly ambiguous. “Prevents some mistakes” would be more clear, but I also don’t read “prevents” as “eliminates the possibility of”.
galangalalgol 3y ago
What sorts of errors with ref counting are possible?
- diarrhea 3y ago
  One guess: memory leaks from circular references. It’s ref counting, and doesn’t do roots checking.
  - galangalalgol 3y ago
    Yeah, you can definitely do that. Typically rust features are trying to prevent undefined behavior, specifically exploitable undefined behavior. In doing so there is low hanging fruit for increasing the likelihood correctness but I don't feel like "correctness at any cost" is its motto. That is more Ada territory. Deadlocks and memory leaks can sometimes be exploited for denial of service, but they are not undefined behavior.

kolektiv 3y ago

You can. There are definitely still footguns - some things are just not easy. But there are also fewer footguns, and the overall type system makes modelling problems in ways which are often simpler to reason about more achievable (trivial example - state machines are common, and easy to represent in relatively safe ways with exhaustively checked enums, matching, etc.) Is rewriting something in Rust a guarantee of no bugs? Nope. But it does likely make it easier for the rewriters to reduce the number of bugs.

danudey 3y ago
Also, since Rust provides and enforces the mechanisms to bypass huge swaths of bugs, like many locking errors, concurrency, exhaustive enum checking, etc., that frees up developers to spend their time debugging or reinforcing other areas where Rust can't make similar guarantees of correctness. I recall reading somewhere that a lot of the ideas for Rust's safety system came from a Firefox analysis of bugs that had been reported and fixed, where something like 70% of bugs fell into a few broad categories (mostly memory safety, like use-after-free, buffer overruns, off-by-one, etc) which they could solve in a new language that could enforce correctness. The idea of being able to remove 70% of bugs, and to effectively guarantee that any bugs that do occur happen in those remaining 30% of areas, sounds like it could save a lot of developer time.

pornel 3y ago

All mistakes is such an unachievable high bar, it’s almost a strawman argument. You can always imagine a programmer terrible enough that they will find every possible failure case. However, Rust can prevent quite a lot of common mistakes. Getting rid of UAF, data races, and having deterministic destruction that unlocks locks is already a major quality improvement. Rust can’t prevent deadlocks caused by wrong architecture, but of all concurrency issues deadlocks are the easiest to diagnose.

imtringued 3y ago
> You can always imagine a programmer terrible enough that they will find every possible failure case. Uhh, no. That is an amazing programmer! Why? Because truly terrible programmers imagine a subset of every possible failure case and simply refuse to acknowledge other failure cases, especially the ones that are particularly common with particularly severe consequences.

bfrog 3y ago

Rust can prevent races. It cannot guarantee no Deadlocks by itself. However, there are schedulers that do guarantee deadlock free operation written in Rust, see RTIC for example.