답변.

문제의 역사:

멀티스레딩 작업은 대부분의 프로그래밍 언어에서 오류의 원인입니다: 데이터 경쟁, 자원 경쟁, 명백하지 않은 버그. C++와 자바의 경험을 연구한 러스트의 창립자들은 대부분의 오류가 컴파일 시점에 발견될 수 있도록 스레드 안전 메커니즘을 타입 시스템에 내장하기로 결정했습니다.

문제:

전통적인 언어에서는 종종 프로그래머의 규율과 외부 도구에 의존해야 합니다: 데이터 소유권 전송의 위험, 공유 및 수정 가능한 메모리, 동시 접근에 대한 통제가 없으면 중대한 실패를 초래할 수 있습니다. 컴파일 단계에서 메모리 경쟁이 없도록 보장하는 시스템이 필요했습니다.

해결책:

러스트에서는 스레드 간 데이터 전달 및 동기화를 위해 표준 라이브러리의 특수 타입인 Arc, Mutex 및 채널을 사용합니다. 컴파일러에 의해 자동으로 확인되는 Send 및 Sync 트레이트 마커가 핵심 역할을 합니다. 타입이 스레드 안전(thread-safe) 하려면:

안전한 타입만 스레드 간에 공유될 수 있어야 합니다(Sync)
타입은 Send를 구현하는 경우에만 스레드 간에 전달될 수 있습니다.

코드 예시:

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);
        let handle = thread::spawn(move || {
            let mut num = counter.lock().unwrap();
            *num += 1;
        });
        handles.push(handle);
    }
    for handle in handles {
        handle.join().unwrap();
    }
    println!("결과: {}", *counter.lock().unwrap());
}

주요 특징:

동기화 원시타입 Mutex, RwLock, 채널은 계약상 스레드 안전입니다.
데이터 접근 전달은 포인터가 아닌 래퍼 타입(Arc, Mutex)을 통해 이루어집니다.
Send/Sync 시스템은 잘못된 스레드 간 안전하지 않은 구조의 공유를 허용하지 않습니다.

속임수 질문.

왜 Rc<T>를 스레드 간 데이터 전송에 사용할 수 없는가?

Rc<T>는 Send 트레이트를 구현하지 않으며 스레드 안전하지 않습니다 — 내부 구현은 비차단 방식의 참조 카운터에 기반해 있으며, 이는 여러 스레드에서 접근할 경우 데이터 레이스를 초래할 수 있습니다. 스레드에서는 Arc<T>를 사용하세요.

자신의 타입에 대해 Send 또는 Sync를 수동으로 구현하여 컴파일러의 제한을 우회할 수 있나요?

가능하지만 매우 위험합니다! 불변성을 위반하면 (예: 벌거벗은 포인터를 공유하면) 데이터 레이스가 발생할 수 있습니다. 스레드 안전 타입에 대해 완전히 확신하는 전문가만 수동 구현을 남겨두세요.

Mutex가 Rust에서 데드락을 유발할 수 있는 경우와 이를 피하는 방법은?

여러 뮤텍스를 캡처하는 순서가 불안정하거나 한 스레드에서 중첩하여 차단되는 경우 데드락이 발생할 수 있습니다 (Mutex는 재진입 가능하지 않음!).

use std::sync::Mutex;
let a = Mutex::new(0);
let _g1 = a.lock().unwrap();
let _g2 = a.lock().unwrap(); // panic: deadlock!

전형적인 오류 및 안티패턴

여러 스레드 간 접근을 위해 Rc 대신 Arc 사용
스레드 간 공유되는 타입에서 mut 레퍼런스나 원시 포인터 저장
lock() 작업 시 unwrap 확인을 잊음

실생활 예

부정적인 사례

개발자가 웹 서버에서 스레드 간 상태를 전달하기 위해 Rc<RefCell<T>>를 사용했습니다. 로컬 테스트에서는 작동했지만 프로덕션에서는 레이스 조건이 발생했습니다: 변수들이 "상태를 잃어버리거나", 서버가 다운되는 경우가 발생했습니다.

장점:

간단하고 간결한 코드

단점:

동적 경쟁, 크래시, 수정할 수 없는 버그, 보안 취약점

긍정적인 사례

상태를 전달할 때 Arc<Mutex<T>> 사용, Send/Sync 준수, 채널을 통한 스레드 작업 분배, 스레드 간에 공유 데이터의 mut 사용 없음.