4 ms·

I didn't know rust was able to tell when a method is thread safe. Where can I read more about that/try it out?

by helltone 2y ago

remexre 2y ago
Send and Sync are the keywords to search for.
metaltyphoon 2y ago
Isn’t anything with Arc thread safe?
- ab5tract 2y ago
  Telling when a thing is thread safe is hardly the same as telling when something isn’t.
- ninkendo 2y ago
  No. Just because something’s behind an Arc<T> doesn’t mean two threads can hold it at once. Arc just ensures that it is freed (dropped) when no threads are using it any more. T itself has to be Send+Sync for Arc to be. To a first approximation, Arc<Mutex<T>> is what you want when you want a blob of mutable stuff to just work between threads, but you still have to worry about terrible performance if you hold the mutexes too long, etc. (Not to mention mutexes are just slower in general than having types which are natively Send+Sync.)
  - jpc0 2y ago
    > Not to mention mutexes are just slower in general than having types which are natively Send+Sync Without knowing the implementation, how would you know this statement is true? I could just stick the Arc<Mutex<T>> within my abstraction and say it is send+sync and it would have the exact same performance, and that might be the most efficient solution possible on the given hardware.
    - deleted 2y ago
      [deleted]
aaomidi 2y ago
Race conditions within rust are technically impossible :)
- jrpelkonen 2y ago
  Safe Rust prevents data races, but not race conditions in general.
  - CryZe 2y ago
    Though arguably, the fact that in order to mutate data from multiple threads, the compiler,forces you to use some synchronization primitive, results in you having to think about how you are going to synchronize access, which should lower the chance of race condition bugs overall.
  - tialaramex 2y ago
    The analogy I find helpful for this is, you let the cat out your front door and close it. You walk to the back door and close that too. A race condition (which safe Rust can have) is a normal phenemenon in our world. If we put the cat out the front door, then walk to the kitchen and close that door by the time we reached the back door maybe the cat had run around the outside of the building and come inside again, closing the doors in the wrong order introduced the opportunity for a race - be very careful. A data race (which safe Rust does not have) is a weird thing caused by the mismatch between how you think the computer works and how it actually works. What happens if Alice tries the put the cat out the front door at the same time Bob tries to put it out the back door? Well, in the real world that cannot happen, either Alice has the cat or Bob does. But for many languages† this sort of nonsense can happen and when it does that's a disaster † In safe Rust it can't happen, in Java, OCaml and Go it can happen, but it may not be a disaster (the details are different for each, it is a bug though).
    - irundebian 2y ago
      Interesting analogy.
  - aaomidi 2y ago
dagmx 2y ago
It’s probably more correct if I say that data types themselves are thread safe or not. https://doc.rust-lang.org/nomicon/send-and-sync.html https://doc.rust-lang.org/nomicon/send-and-sync.html So therefore a function can’t do things that invalidate that type level contract.

I didn't know rust was able to tell when a method is thread safe. Where can I read more about that/try it out?

remexre 2y ago

Send and Sync are the keywords to search for.

metaltyphoon 2y ago

Isn’t anything with Arc thread safe?

ab5tract 2y ago
Telling when a thing is thread safe is hardly the same as telling when something isn’t.
ninkendo 2y ago
No. Just because something’s behind an Arc<T> doesn’t mean two threads can hold it at once. Arc just ensures that it is freed (dropped) when no threads are using it any more. T itself has to be Send+Sync for Arc to be. To a first approximation, Arc<Mutex<T>> is what you want when you want a blob of mutable stuff to just work between threads, but you still have to worry about terrible performance if you hold the mutexes too long, etc. (Not to mention mutexes are just slower in general than having types which are natively Send+Sync.)
- jpc0 2y ago
  > Not to mention mutexes are just slower in general than having types which are natively Send+Sync Without knowing the implementation, how would you know this statement is true? I could just stick the Arc<Mutex<T>> within my abstraction and say it is send+sync and it would have the exact same performance, and that might be the most efficient solution possible on the given hardware.
  - deleted 2y ago
    [deleted]

aaomidi 2y ago

Race conditions within rust are technically impossible :)

jrpelkonen 2y ago
Safe Rust prevents data races, but not race conditions in general.
- CryZe 2y ago
  Though arguably, the fact that in order to mutate data from multiple threads, the compiler,forces you to use some synchronization primitive, results in you having to think about how you are going to synchronize access, which should lower the chance of race condition bugs overall.
- tialaramex 2y ago
  The analogy I find helpful for this is, you let the cat out your front door and close it. You walk to the back door and close that too. A race condition (which safe Rust can have) is a normal phenemenon in our world. If we put the cat out the front door, then walk to the kitchen and close that door by the time we reached the back door maybe the cat had run around the outside of the building and come inside again, closing the doors in the wrong order introduced the opportunity for a race - be very careful. A data race (which safe Rust does not have) is a weird thing caused by the mismatch between how you think the computer works and how it actually works. What happens if Alice tries the put the cat out the front door at the same time Bob tries to put it out the back door? Well, in the real world that cannot happen, either Alice has the cat or Bob does. But for many languages† this sort of nonsense can happen and when it does that's a disaster † In safe Rust it can't happen, in Java, OCaml and Go it can happen, but it may not be a disaster (the details are different for each, it is a bug though).
  - irundebian 2y ago
    Interesting analogy.
- aaomidi 2y ago

dagmx 2y ago

It’s probably more correct if I say that data types themselves are thread safe or not. https://doc.rust-lang.org/nomicon/send-and-sync.html https://doc.rust-lang.org/nomicon/send-and-sync.html So therefore a function can’t do things that invalidate that type level contract.