4 ms·
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 th
by 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 agoWell, 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 agoRust-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 agoYeah 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 agoIf 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 agoI 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 agoA difference being that you're safe even without a Mutex at zero cost.
- loeg 3y agofolly::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 agoFairly ambiguous. “Prevents some mistakes” would be more clear, but I also don’t read “prevents” as “eliminates the possibility of”.
- galangalalgol 3y agoWhat sorts of errors with ref counting are possible?
- diarrhea 3y agoOne guess: memory leaks from circular references. It’s ref counting, and doesn’t do roots checking.
- galangalalgol 3y agoYeah, 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.