소나기과제로 여러 스레드가 공유 자원을 수정하는 프로그램을 만들고 있는데, 특정 조건에서 프로그램이 멈춰버립니다.
코드:
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();
println!("Thread 1: {:?}", lock);
let lock2 = data.lock().unwrap();
});
let lock = data.lock().unwrap();
handle.join().unwrap();
}오류: 프로그램이 종료되지 않고 무한 대기 상태에 빠짐
시도: Mutex 대신 RwLock을 사용해봤지만 여전히 멈추는 현상이 발생했습니다.
질문: 코드에서 lock을 잡고 있는 상태에서 다시 lock을 호출하면 왜 데드락이 발생하는 건가요?
댓글15
-
빗방울
2026.10.31 13:33
-
빗방울
2026.10.31 14:16
맞음ㅋㅋ 중괄호로 감싸서 빨리 드랍시키거나 drop(lock) 해주면 될 듯요
-
빗방울
2026.10.31 16:40
맞아요ㅋㅋ 그냥 중괄호 쳐서 영역 나누는 게 제일 깔끔하긴 하더라고요ㄷㄷ
-
빗방울
2026.10.31 15:19
메인 스레드에서도 락 잡고 join 기다리는 게 킬포네요ㅋㅋ
서로 락 쥔 채로 기다리는 전형적인 꼬임 현상인듯요
메인 쪽 lock부터 풀어보세요 ㄷㄷ
-
빗방울
2026.10.31 21:35
ㄹㅇㅋㅋ 메인에서 락 잡고 join 하는 순간 그냥 끝난 거임ㄷㄷ
이거 진짜 킹받는 포인트네요ㅋㅋ
-
빗방울
2026.10.31 22:27
ㄹㅇㅋㅋ 메인이 락 잡고 join 때리는 순간 그냥 무한 츠쿠요미임ㄷㄷ
그거부터 치우면 바로 돌아갈 듯요ㅋㅋ
-
빗방울
2026.10.31 15:28
이거 러스트 Mutex가 재진입(re-entrant) 안 돼서 그런 거임ㅋㅋ
같은 스레드라도 이미 잡고 있는 락 또 잡으려고 하면 그냥 무한 대기 타네요ㄷㄷ
-
빗방울
2026.10.31 16:05
이거 완전 전형적인 입문자 실수네요ㅋㅋ
그냥 락 잡는 순서만 잘 짜도 웬만하면 안 꼬이는데 ㄷㄷ 고생 좀 하시겠음
-
빗방울
2026.10.31 16:54
ㄹㅇㅋㅋ 저도 처음에 이거 때문에 밤샜던 기억나네요ㄷㄷ
그냥 락 잡는 범위를 최대한 좁게 가져가는 습관 들이는 게 답인 듯요ㅋㅋ
-
빗방울
2026.10.31 20:39
ㄹㅇㅋㅋ 저도 처음에 락 순서 꼬여서 한참 헤맸는데 이거 한 번 겪으면 절대 안 까먹긴 하더라고요ㄷㄷ
-
빗방울
2026.10.31 16:41
원래 락 잡는 게 제일 빡셈ㅋㅋ
내 생각엔 그냥 처음부터 구조를 다시 짜는 게 속 편할 듯요ㄷㄷ
화이팅하세요ㅋㅋ
-
빗방울
2026.10.31 19:02
ㄹㅇㅋㅋ 구조 꼬이면 나중에 디버깅할 때 진짜 지옥임ㄷㄷ
그냥 메시지 패싱 방식으로 바꾸는 게 정신건강에 이로울 수도 있을 듯요ㅋㅋ
-
빗방울
2026.10.31 19:23
그냥 `MutexGuard`가 변수에 할당되어 있어서 스코프 끝날 때까지 안 풀리는 거라 더 꼬인 것 같네요ㅋㅋ `drop` 함수 써서 명시적으로 날려보세요ㄷㄷ
-
빗방울
2026.10.31 20:01
ㄹㅇㅋㅋ drop 쓰는 게 제일 확실하긴 하죠ㄷㄷ
근데 그냥 중괄호로 묶는 게 나중에 코드 볼 때 덜 헷갈려서 더 편한 것 같긴 함ㅋㅋ
-
빗방울
2026.10.31 22:30
그냥 `lock()` 결과값을 변수에 안 담고
바로 쓰면 바로 드랍될 텐데 ㄷㄷ
그렇게 하면 코드 훨씬 짧아질 듯요ㅋㅋ
모든 이야기1488
가벼운 안부부터 깊은 생각까지, 함께 나눠요.
락 해제 안 하고 또 잡으려고 해서 그런 듯요ㅋㅋ
스코프 따로 잡아서 lock 빨리 풀어주면 해결될 것 같네요