3 ms·

How does rust perform in parallel on the same memory? I heard it uses locks? This is not on the same memory right? https://news.ycombinator.com/item?id=214692

• asdkhadsj 7y ago
  The same as any language, if you were to write safe code at least. By safe code I mean, if you wrote Go in such a way that race conditions could not happen, you typically would write it in the same way in Rust. Often this involves Mutexes, but there are plenty of libraries that set up foundations for parallel behavior without Mutexes. So it can operate on "the same memory", and there are a whole lot of ways to manage it safely. The right tool for the right job, really.
  • whb07 7y ago
    this isn't quite right, this feels like what the standard response from a developer with some hubris. Humans are fallible and mushy, and depending on their current state are error prone. So why not just codify some "best practices" that are built in as primitives to a language like Rust? There are ways to perform parallel work that is "safe", Rust solves this with the borrow/checker implementation, another clear "safe" way would be to make everything immutable as seen on Haskell, Ocaml, F# to where who cares about who gets to what first if the underlying thing will never change. Mutexes and locks and all the other ways of doing parallel work that is "safe" isn't a primitive thats cooked in with the language.
    • asdkhadsj 7y ago
      Sorry, maybe I misunderstood OP. I was responding to what I thought was a general, vague question about how something safe might work in Rust, compared to other languages (Go in my example). So while I don't think what I said was incorrect re: Go vs Rust concurrency, perhaps I misunderstood OPs question. > Mutexes and locks and all the other ways of doing parallel work that is "safe" isn't a primitive thats cooked in with the language. I didn't understand OPs question as strictly features cooked into the language, so I was not saying that. With that said, if you're not allowing for Mutexes for "safe things that are cooked into the language" I feel like you won't like Rust. This is an odd metric, though. edit: words
• littlestymaar 7y ago
  What do you mean by “on the same memory” exactly? If you want two threads running in parallel to concurrently access the same memory location you don't need synchronization if you only perform reads, and you need one if there is at least one write. Like in any other language (this comes directly from how CPU works). The good thing with Rust is that you can't shoot yourself in the foot: if you can't accidentally have an unsynchronize mutable variable accessible from two threads: the compiler will show you an error (unless you explicitely opt out this security by using unsafe primitives, in which case the borrow checker will let you go).
  • bullen 7y ago
    I mean just like it reads: I want two (or more) threads to write the same memory at the same time. This is a problem Java "solved"/"worked around" with a complete memory model rewrite for the whole JDK and the concurrency package in 2004 (1.5). The solutions range from mutexes to copy-on-write and more.
    • oconnor663 7y ago
      My understanding is that Rust is basically equivalent to C in this regard, in terms of concurrent writes to the same memory being per se undefined behavior. I think the JVM translates concurrent memory writes into hardware-appropriate atomics, so maybe a better translation from Java to Rust would be a large `Vec<AtomicUsize>` or something like that, rather than raw memory?
    • unlinked_dll 7y ago
      you can use whatever synchronization techniques you want, from lock free data structures/queues, to mutexes, to unadulterated unsafe reads/writes to raw pointers. std provides some useful helpers like Arc and Mutex (Arc<Mutex<Type>> is always safe to use across threads, as the lifetime is managed safely by Arc and accesses handled by Mutex). There are crates out there for things like lock free sync and other GC if you need it. Rust doesn't force you into a single world view.