It might have been nice to mention that the best practice is to lock the mutex (or any kind of lock) for as little time as possible. Putting the lock() call and (omg, really, no unlock yet?) drop() on either side of the add_assign() inside the loop would, theoretically lock and unlock the mutex during each loop and give control back and forth as quickly as possible. Otherwise, great content, and thanks for making the topic accessible!
Cool, was confused a bit while reading the book, but things made clearer here. So in the book, they have used Arc so share and update the data between the threads. In this video we have used "thread::scope" to share Mutex across threads and modify the data inside. So what I've understood is there are two ways we can reference the data from the main thread inside the spawned thread and then alter it inside the spawned thread. So what might be the differences between these approaches?. Like when to use Arc to share the data across the threads or when to use thread::scope to share the data?
wouldnt you just derefence the MutexGuard to work with the data? is there some benefit to working with the MutexGuard's methods instead of derefencing it?
Demo of join part is not doing what you think. The second thread never runs concurrently, join forces it to run now. Test wirh lock/unlock inside loop to show thread working concurrently.
It might have been nice to mention that the best practice is to lock the mutex (or any kind of lock) for as little time as possible. Putting the lock() call and (omg, really, no unlock yet?) drop() on either side of the add_assign() inside the loop would, theoretically lock and unlock the mutex during each loop and give control back and forth as quickly as possible. Otherwise, great content, and thanks for making the topic accessible!
Thanks for the video. I have a hard time learning from just text so it helps a lot to have a voice to the material.
Cool, was confused a bit while reading the book, but things made clearer here. So in the book, they have used Arc so share and update the data between the threads. In this video we have used "thread::scope" to share Mutex across threads and modify the data inside. So what I've understood is there are two ways we can reference the data from the main thread inside the spawned thread and then alter it inside the spawned thread.
So what might be the differences between these approaches?. Like when to use Arc to share the data across the threads or when to use thread::scope to share the data?
Which book?
@@RahulYadav-dd7qe The rust book. Available on rust official website.
man i really thank you from my hear for these videos... finally i found someone that can explains rust with a simple way that i can understand
Thank you for your efforts really appreciate the clear voice and explanation and efforts put in the video
wouldnt you just derefence the MutexGuard to work with the data? is there some benefit to working with the MutexGuard's methods instead of derefencing it?
I love this!! this was a charm
Demo of join part is not doing what you think. The second thread never runs concurrently, join forces it to run now.
Test wirh lock/unlock inside loop to show thread working concurrently.
Thanks for calling that out.
how about std::sync::mpsc ... is it an advance topic?
I'm actually planning to do that topic today!!
@@TrevorSullivan ❤️🙏 I appreciate you