이력적으로, Rust는 단일 스레드 시나리오를 위한 성능 위주의 대안으로 Arc (원자적 참조 카운팅)에 대한 Rc (참조 카운팅)를 도입했습니다. 초기 버전의 언어는 이 구분이 없어 모든 공유 소유가 원자적 연산의 비용을 부담하게 만들었습니다. Send 및 Sync 자동 트레이트는 스레드 안전성을 구성적으로 강제하기 위해 설계되었으며, 컴파일러가 타입의 구성 요소에 따라 이러한 속성을 자동으로 유도할 수 있도록 합니다.
핵심 문제는 Rc의 내부 구현으로, 활성 참조를 추적하기 위해 비원자적 카운터(일반적으로 Cell<usize> 또는 UnsafeCell<usize>로 래핑됨)를 사용합니다. 이 설계는 메모리 장벽의 오버헤드를 피하기 위해 단일 스레드 접근을 가정합니다. 만약 Rc<T>가 Send를 구현할 수 있었다면, 프로그램은 포인터의 복제본을 다른 스레드로 이동시킬 수 있습니다. 새 스레드에서 파괴하거나 복제하는 과정에서 두 스레드는 참조 카운트에 대해 동기화되지 않은 읽기-변경-쓰기 작업을 수행하게 됩니다. 이는 데이터 경쟁을 구성하며, 이로 인해 카운트가 손상되고 조기 해제(사용 후 해제) 또는 메모리 누수(이중 해제)가 발생할 수 있습니다.
해결책은 구조적으로, Rc는 스레드 안전하지 않은 타입을 포함(또는 현대 Rust에서의 부정적 구현을 통해)하여 Send 및 Sync에서 명시적으로 제외됩니다. 이는 개발자에게 크로스 스레드 공유를 위해 Arc<T>를 사용하도록 강제하며, AtomicUsize를 카운터로 사용하여 모든 CPU 코어에서 증분 및 감소 작업이 원자적이고 정확하게 순서화되도록 보장합니다. 컴파일러는 타입 수준에서 이 구분을 강제하며, 런타임 검증 없이 우연한 공유를 방지합니다.
대용량 문서를 추상 구문 트리(AST)로 구문 분석하는 고성능 텍스트 편집기를 고려하십시오. 파서는 Rc<Node>를 사용하여 트리 전반에 걸쳐 공유 하위 문자열(예: 동일한 식별자)을 나타내어 단일 스레드 구문 분석 단계에서 메모리를 최적화합니다. 하위 트리를 스레드 풀에 분배하여 의미 검증을 병렬화해야 할 필요성이 대두됩니다.
즉시 발생하는 문제는 Rc<Node>를 작업 스레드로 보내려 할 때 컴파일이 실패한다는 것입니다. 여러 솔루션이 평가되었습니다:
모든 Rc 인스턴스를 Arc로 전역적으로 교체: 모든 Rc 인스턴스를 Arc로 대체합니다. 장점: 최소한의 코드 변경 및 즉각적인 스레드 안전성. 단점: 프로파일링 결과, 구문 분석 중 불필요한 원자적 연산으로 인해 12-15%의 처리량 감소가 나타나 성능 예산을 위반했습니다.
전송을 위한 깊은 복제: 하위 트리를 Vec<u8>로 직렬화하고 바이트를 전송한 후 작업자에서 역직렬화합니다. 장점: 안전하지 않은 코드나 구조적 변경이 없습니다. 단점: 복잡한 그래프 구조를 마샬링하는 데 높은 지연 시간 및 CPU 비용이 소요되며, 실시간 편집에는 제한적입니다.
안전하지 않은 포인터 추출: Rc를 원시 포인터로 변환하고 포인터를 전송한 후 수신자에서 Rc를 재구성합니다. 장점: 0복사 오버헤드. 단점: 근본적으로 안전하지 않으며 Rc의 소유 불변성을 위반합니다(수신 스레드는 전송 스레드가 복제를 중단했는지 알 수 없음), 결국 메모리 손상 또는 덩그러니 있는 포인터를 유발합니다.
채널 기반 작업 배포: 주 스레드에서 AST를 유지하고 경량 검증 작업(바이트 범위 또는 노드 인덱스)을 crossbeam 채널을 통해 전송합니다. 작업자는 Rc가 관리하는 메모리에 접근하지 않고 결과를 반환합니다. 장점: 구문 분석을 위한 Rc 성능을 유지하고, 안전하지 않은 코드 없이 데이터 경쟁을 제거하며 구성 요소를 분리합니다. 단점: 검증 알고리즘을 데이터 병렬에서 작업 병렬로 재구성해야 합니다.
팀은 채널 기반 접근 방식을 선택했습니다. 파서는 단일 스레드 및 빠른 상태로 유지되었으며, 검증은 코어 수에 따라 선형으로 확장되었습니다. 결과는 안전하지 않은 블록이 없고 성능 특성이 유지된 안정적인 시스템이었습니다.
포장된 타입 T가 Sync인 경우에도 Rc<T>가 여전히 !Sync인 이유는 무엇이며, 이 것이 Send 제한과 어떻게 다른가요?
Rc<T>는 불변 참조(&Rc<T>)가 **.clone()**을 호출할 수 있도록 하여 내부 비원자적 참조 카운트를 변형하게 하므로 Sync일 수 없습니다. T 자체가 공유하기에 안전(Sync) 하더라도, 여러 스레드에서 참조를 공유하는 것은 여러 스레드에서 카운트를 동시에 증가시킬 수 있게 하여 데이터 경쟁을 유발합니다. Send 제한은 소유권이 다른 스레드로 전송되는 것을 방지하며, Sync 제한은 참조의 스레드 간 공유조차 방지합니다. Rc는 "읽기 전용" 작업(복제)이 실제로 내부 변형을 수행하기 때문에 두 가지 원칙 모두를 위반합니다.
PhantomData<T>가 원시 포인터(const T)를 감싸는 사용자 정의 구조체에 대해 Send 및 Sync의 자동 유도에 어떤 영향을 미치며, 그 포함이 중요한 이유는 무엇입니까?*
PhantomData 없이 *const T를 포함하는 구조체는 자동 트레이트 유도를 위해 T와 연결되는 타입 정보를 지니고 있지 않습니다. 컴파일러는 포인터가 덩그러니 있을 수 있고, 임의로 별칭이 붙거나 스레드 로컬 데이터에 지시할 수 있다고 보수적으로 가정하고 Send 또는 Sync를 유추하는 것을 거부합니다. PhantomData<T>를 포함시킴으로써, 개발자는 구조체가 논리적으로 T를 소유하고 있음을 컴파일러에 신호를 보냅니다. 결과적으로, T가 Send를 구현하는 경우 구조체는 자동으로 Send를 구현하고, T가 Sync를 구현하는 경우 Sync를 구현하여 FFI 래퍼 또는 사용자 정의 스마트 포인터에 중요한 구성적 스레드 안전성을 복원합니다.
특정 조건 하에 trait 객체 Box<dyn Trait>가 기본 구체적 타입이 Send를 구현하더라도 Send 자동 트레이트를 잃는 이유는 무엇입니까?
trait 객체 dyn Trait는 trait 정의가 명시적으로 Send를 상위 경계로 요구하는 경우에만 Send를 구현합니다(예: trait Trait: Send). 구체적 타입을 trait 객체로 지우면, 컴파일러는 자동 트레이트 구현을 포함한 모든 특정 타입 정보를 폐기합니다. trait 자체가 Send를 보장하지 않는 한, 컴파일러는 vtable이 스레드 안전한 메소드에 지시하는지를 검증할 수 없습니다. 이는 trait 경계가 명시적으로 Send(및 Sync)를 포함하지 않는 한, 박스된 trait 객체를 스레드 경계를 넘어 전송하는 것을 방지합니다.