Hi Guys , my task is write a func which multiple &mut paras , and do some stuff with them in a thread but the problem is Rust rules does not let me . What do i have to do?
The only way i can think of is doing some unsafe Rust code , which is getting address of that data in memory and do the stuff manually
And that's how you get undefined behavior and race conditions.
Just use a mutex.
I know about Arc and Mutex , but i think its not possible to use them with &mut , and para which the function gets must be &mut
The whole point of a mutex is that you can have a &Mutex<T> and get a &mut T out of it by locking it.
It requires to the i create Mutex::new() type at first i think isn't it? And then i can do what u say
Am i wrong? If not this means Mutex cannot solve the problem because i get variable of type &mut Vec for example
Just show actual code. It's impossible to tell what's wrong based on your vague natural language description.
Rust doesn't prevent multi-threading. People are doing MT in Rust just fine. You are likely seriously misunderstanding something.
1 Like
Yes, you would create a Mutex<Vec<T>>.
Just to take a few steps back: The answer to your original question is basically "No", you can't do that without making the operation safe first, for instance via a Mutex, as suggested by @paramagnetic.
I know you said you need to pass &mut's to your threads, but are you saying that only to imply that you need to write to them, or do you need to share+write them between threads? If it's the former, then you might consider passing ownership instead; that will allow you to get mutable access without locking. However, if you're asking because you want mutable access to the same Vec on multiple threads, then there's no way to do that without wrapping the Vec in something that'll force you to not to commit memory-safety related crimes (like a Mutex).
Imagine this function
fn smth(data : &mut Vec<u8>){
// some stuff
std:: thread::spawn(||{
// using rayon
data.par_iter_mut().for_each(|(d , &value)|{
// smth
}
}
Rayon alone works fine , but thread alone nope
If you want the code inside thread::spawn to work after smth returns, you must have an owned Vec, not a reference. Otherwise, Vec might be dropped while thread is still running - that's use-after-free, hence UB.
If you want smth to wait for code inside thread::spawn before returning, you want not thread::spawn, but thread::scope.
4 Likes
whats thread::scope?
This.
3 Likes
sounds like what i need , thanks man ill test it out
I fixed by some unsafe operations which i would use in C like code , like keeping the memory address and referring to it for write ops
Thanks you all for your suggestions
Chances are you are causing UB. Are you performing additional synchronization? If not, you are causing a data race.
3 Likes
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.