Arc<Mutex> 로 공유 상태

다른 협력 스타일은 공유 상태야: 여러 스레드가 한 데이터를 읽고 써. 위험은 뻔해 — 두 스레드가 동시에 쓰면 망가져. Rust 의 안전한 공유-가변 타입은 Arc<Mutex<T>> 야.

Mutex: 한 번에 한 스레드

Mutex<T> (mutual exclusion) 가 안쪽 값을 지켜: 스레드가 .lock() 을 불러 배타적 접근을 얻고, 첫 스레드가 풀기 전엔 다른 스레드가 락 못 해. lock 은 guard 를 반환하고; guard 통해 변형하고, guard 가 drop 되면 (스코프 끝 — 또 RAII) 락이 자동 해제돼. 락을 쥐지 않고선 데이터에 말 그대로 닿을 수 없어.

Mutex 를 공유하려고 Arc

Mutex 혼자선 owner 하나야. 여러 스레드가 닿게 하려면 Arc 로 감싸: Arc<Mutex<T>>. 각 스레드가 같은 Mutex 로의 clone 된 Arc 핸들을 얻어. Arc 가 스레드 간 소유권을 공유하고; Mutex 가 접근을 직렬화해. Smart Pointers 트랙의 Rc<RefCell<T>> 의 정확한 멀티스레드 평행이야.

Arc 가 소유권을 공유; Mutex 가 접근을 직렬화. 같이, Arc<Mutex<T>> 가 여러 스레드한테 안전한 공유-가변 접근을 줘: 공유하려고 Arc clone, 한-번에-하나 변형하려고 Mutex lock. 락 guard 의 Drop 이 자동 해제해 — unlock 까먹을 수 없어.

컴파일러가 여전히 뒤를 봐줘

락 없이 데이터를 실수로 못 읽어 — 값이 Mutex 안 에 살아서 .lock() 통해서만 닿거든. 그리고 Arc 없이 맨 Mutex 를 스레드 간 공유 못 해; 컴파일러가 요구해. 다른 언어에서 제일 위험한 '공유 가변 상태' 경로조차 여기선 구조적으로 race-free 야.

Code

열 스레드가 공유 카운터를 안전하게 증가·rust

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        handles.push(thread::spawn(move || {
            let mut n = counter.lock().unwrap(); // 배타적 접근
            *n += 1;
        })); // 락 guard 가 여기서 drop -> 락 해제
    }
    for h in handles {
        h.join().unwrap();
    }

    println!("final: {}", *counter.lock().unwrap()); // 항상 10
}

Exercise

5 스레드 간 공유되는 Arc<Mutex<Vec<i32>>> 를 써; 각 스레드가 자기 id 를 벡터에 push 해. 다 join 한 뒤 정렬된 벡터를 출력하고 5 개 id 가 다 있는지 확인해. push 순서는 비결정적인데 왜 최종 결과는 내용상 결정적이야?

Hint

Mutex 가 각 push 를 배타적으로 보장해서 push 가 하나도 안 잃어 — 5 개 id 다 들어가. 들어가는 순서는 비결정적 (스케줄러 의존) 이라, 결정적 표시를 위해 출력 전에 정렬하는 거야.

Arc<Mutex> 로 공유 상태

Mutex: 한 번에 한 스레드

Mutex 를 공유하려고 Arc

컴파일러가 여전히 뒤를 봐줘

Code

External links

Exercise

Progress

댓글 0