Tracking Issue for Mutex and RWLock unique accessors #28968
Description
After #29031, this is now the tracking issue for the stabilization of the following features:
- mutex_into_inner
- mutex_get_mut
- rwlock_into_inner
- rwlock_get_mut
Original report
As far as I can tell, it's sound to straight-up-unwrap a Mutex if you have it by value. This would enable one to do:
let data = Mutex::new(vec![])
crossbeam::scope(|scope| {
for input in inputs {
let data = &data;
scope.spawn(move || {
let output = expensive_computation(input);
data.lock().unwrap().push(output);
}
}
});
for expensive in data.into_inner() {
non_thread_safe(expensive);
}Which today requires mutexing an &mut:
let mut data = vec![];
{
let data_mutex = Mutex::new(&mut data);
crossbeam::scope(|scope| {
for input in inputs {
let data = &data_mutex;
scope.spawn(move || {
let output = expensive_computation(input);
data.lock().unwrap().push(output);
}
}
});
}
for expensive in data.into_inner() {
non_thread_safe(expensive);
}Given Arc can be unwrapped, this would also allow the last Arc<Mutex<T>> in some concurrent context to be fully unwrapped to a T.