과제로 멀티스레딩 환경에서 공유 자원을 업데이트하는 프로그램을 작성하고 있습니다. 여러 스레드가 동시에 데이터를 수정하고 읽어야 하여 Arc와 Mutex를 사용하였습니다.
코드:
use std::sync::{Arc, Mutex};
use std::thread;
fn main() {
let data = Arc::new(Mutex::new(0));
let data_clone = Arc::clone(&data);
let handle = thread::spawn(move || {
let lock = data_clone.lock().unwrap();
let _inner_lock = data_clone.lock().unwrap();
println!("Thread: {}", *lock);
});
let lock = data.lock().unwrap();
println!("Main: {}", *lock);
handle.join().unwrap();
}
오류: 프로그램이 출력 없이 무한 대기 상태(Deadlock)에 빠지며 종료되지 않음.
시도: MutexGuard의 스코프를 제한하기 위해 중괄호 `{}`를 사용해 보았으나, 로직이 복잡해지면서 여전히 락 해제 시점을 제어하는 데 어려움을 겪고 있습니다.
질문: 위 코드처럼 동일한 스레드 내에서 Mutex 락을 중복해서 요청했을 때 발생하는 데드락을 방지하고, 안전하게 값을 업데이트하려면 어떤 구조로 설계하는 것이 가장 효율적일까요?
댓글9
-
빗방울
2026.10.30 15:53
-
빗방울
2026.10.30 17:39
맞아요ㅋㅋ drop() 쓰는 게 제일 확실하긴 함
아니면 그냥 { }로 감싸서 락 빨리 풀어버리세요ㄷㄷ
-
빗방울
2026.10.30 18:05
ㄹㅇㅋㅋ 특히 러스트는 가드 변수가 살아있으면 계속 락 잡고 있어서 더 헷갈리는 듯요ㄷㄷ
-
빗방울
2026.10.30 16:26
이거 로직 꼬이면 답 없죠ㅋㅋ
그냥 `std::sync::atomic` 써보시는 건 어떠세요?
단순 숫자 업데이트면 원자적 타입이 훨씬 편할듯하네요.
-
빗방울
2026.10.30 18:56
ㄹㅇㅋㅋ 단순 카운팅이면 Atomic이 정신건강에 훨씬 이로울 듯요ㄷㄷ
-
빗방울
2026.10.30 16:56
함수 분리해서 락 잡은 상태로 다른 함수 넘기는 식으로 짜면 좀 덜 꼬일 것 같은데 한번 해보셈ㅋㅋ 원래 러스트 락 제어가 처음엔 좀 빡셈ㄷㄷ
-
빗방울
2026.10.30 18:48
재진입 락이 필요하신 거면 parking_lot 라이브러리 써보시는 건 어떠세요ㅋㅋ 표준 Mutex보다 기능도 많고 성능도 더 좋다고 하더라고요ㄷㄷ
-
빗방울
2026.10.30 19:19
아니 근데 애초에 한 스레드에서 락을 두 번 잡을 일이 왜 있나 싶네요ㅋㅋ
그냥 락 잡고 나서 내부 값만 따로 변수에 빼서 쓰고 가드는 빨리 없애버리셈ㄷㄷ
그게 제일 깔끔할 듯요ㅋㅋ
-
빗방울
2026.10.30 20:12
ㄹㅇㅋㅋ 보통 로직 꼬여서 저렇게 짜는 경우가 많은데 그냥 값만 복사해서 쓰고 빨리 드롭하는 게 국룰인 듯요ㄷㄷ
모든 이야기1488
가벼운 안부부터 깊은 생각까지, 함께 나눠요.
동일 스레드에서 락 두 번 잡으면 당연히 데드락나죠ㅋㅋ 그냥 락 잡은 변수 스코프 빨리 끝내거나 drop()으로 직접 날려보세요.