4 ms·
>> 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 languag
by 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.