Note that if only one thread is accessing the struct, you can move the data to the thread, and get it back when you call join on the thread. If there's a lot of data, and would like to prevent copies you could do this with Box.
// Get needs for all actions
pub fn get_needs(&mut self, cur: &SomeState, max_x: &SomeMask) -> NeedStore {
// Run a get_needs thread for each action
let mut vecx: Vec<NeedStore> = self
.avec
.par_iter_mut()
.map(|actx| actx.get_needs(cur, max_x))
.collect::<Vec<NeedStore>>();
// Aggregate the results into one NeedStore
let mut nds_agg = NeedStore::new();
for mut nst in vecx.iter_mut() {
nds_agg.append(&mut nst);
}
nds_agg
}
I noticed that parallel processing can make a mess of multiple diagnostic print statements put in the code, as far as their order displayed on the screen. Simply replacing par_iter with iter, and par_iter_mut with iter_mut, can temporarily restore non-parallel processing.
Yes, this is intended behavior. If you run things in parallel, then their executions could interleave in unpredictable ways, which is why the outputs are messy.