Я столкнулся с этим тупиковым сценарием при работе с Mutex
Структура, которая содержит поле типа Mutex
, выглядит следующим образом:
struct MyStruct {
inner_map: Arc<Mutex<HashMap<i32, Vec<i32>>>>,
}
Я получил доступ к этой внутренней карте через замок на Mutex:
impl MyStruct {
fn test_lock(&self, key: &i32) {
let my_option = self.inner_map.lock().unwrap().remove(key);
if let Some(my_vec) = my_option {
for _inner_val in my_vec {
self.inner_map.lock().unwrap();
println!("Passed test_lock1");
}
}
}
}
Это работает нормально без тупика, так как я удалил значение из HashMap
и получил право владения из HashMap
Очень похожа функция на test_lock с той лишь разницей, что вместо объявления удаленного значения в my_option
переменная использовала его на лету * вызов 1017 * и в этом случае вызывает тупик :
impl MyStruct{
// Why this function goes to deadlock since remove gets the ownership of the data?
fn test_lock2(&self, key: &i32) {
if let Some(my_vec) = self.inner_map.lock().unwrap().remove(key) {
for _inner_val in my_vec {
self.inner_map.lock().unwrap();
println!("Passed test_lock2");
}
}
}
}
Какова основная причина, по которой объявление переменной меняет такое поведение?
Детская площадка