This was fun and very useful, thank you. I will likely re-read it in a few days.
Just one question: An `Arc<Mutex<T>>` allows us to modify the data `T` safely, from multiple threads, right? So besides the "safe shared-state of Arc" there is the data-modification-safety. Plus, we retain ownership of `T` in the main thread I think.
Yes, Arc<Mutex<T>> allows you to modify the data T safely from multiple threads. Because Mutex ensures only one thread can access the inner data at any given moment, preventing data races.
However, you don't exactly "keep ownership in the main thread". Instead, you have almost like a "shared ownership" across all threads that hold a clone of the Arc. All Arc clones point to the same underlying Mutex. The main thread is just one of the threads that keeps ownership of the Arc.
@coderock: Interior mutability was another one of those "why does this exist?" moments for me. The whole "one mutable OR multiple shared references" rule feels so fundamental when learning Rust - then interior mutability comes along and breaks it! But this is for a good reason. Definitely planning a post on that!
All I really needed from you was the bit that the book says, which finally explained to me why the heck they have the names that they do, which helped me finish wrapping my head around the rest, though the rest of what you wrote helped cement it, I think.
Thanks for sharing. Though I found those definitions-focused approaches were exactly what left me confused for months :) That's why I focused on the underlying thread safety principles instead.
This is a great discussion around the internals and Send and Sync. Like you to this point I have read statements like Send can be sent across threads and Sync can be shared across threads but I never really understood why. Much clearer now thank you
This is a very good writeup on Send and Sync, we'd love to include it in the upcoming issue of our newsletter!
Thanks! That's awesome. Really appreciate you including it!
This was fun and very useful, thank you. I will likely re-read it in a few days.
Just one question: An `Arc<Mutex<T>>` allows us to modify the data `T` safely, from multiple threads, right? So besides the "safe shared-state of Arc" there is the data-modification-safety. Plus, we retain ownership of `T` in the main thread I think.
Hi, thanks for reading!
Yes, Arc<Mutex<T>> allows you to modify the data T safely from multiple threads. Because Mutex ensures only one thread can access the inner data at any given moment, preventing data races.
However, you don't exactly "keep ownership in the main thread". Instead, you have almost like a "shared ownership" across all threads that hold a clone of the Arc. All Arc clones point to the same underlying Mutex. The main thread is just one of the threads that keeps ownership of the Arc.
Hope it helps!
It does help. Thanks!
looking forward a deeper explanation of interior mutability and why Rust needs it
@coderock: Interior mutability was another one of those "why does this exist?" moments for me. The whole "one mutable OR multiple shared references" rule feels so fundamental when learning Rust - then interior mutability comes along and breaks it! But this is for a good reason. Definitely planning a post on that!
Check https://marabos.nl/atomics/basics.html#interior-mutability
All I really needed from you was the bit that the book says, which finally explained to me why the heck they have the names that they do, which helped me finish wrapping my head around the rest, though the rest of what you wrote helped cement it, I think.
Similar article is in "Rust Atomics and Locks" https://marabos.nl/atomics/basics.html#thread-safety
Thanks for sharing. Though I found those definitions-focused approaches were exactly what left me confused for months :) That's why I focused on the underlying thread safety principles instead.
By the way, there was a similar observation in https://internals.rust-lang.org/t/updating-the-informal-definition-of-send-and-sync/19956
Interesting! Thanks for sharing.
This is a great discussion around the internals and Send and Sync. Like you to this point I have read statements like Send can be sent across threads and Sync can be shared across threads but I never really understood why. Much clearer now thank you
Thanks! That's exactly the problem I was trying to solve - knowing what but not why. Glad it made more sense!