Rust는 Send 및 Sync와 같은 자동 특성을 도입하여 모든 복합 유형에 대해 수동으로 스레드 안전성을 증명하는 것의 인체공학적 부담을 해소합니다. 역사적으로 시스템 프로그래머는 각 구조체에 복잡한 동시성 계약을 주석으로 달아야 했으며, 이는 오류가 발생하기 쉽고 장황했습니다. 컴파일러는 집합체 유형(구조체, 열거형, 튜플)에 대해 모든 구성 필드가 이를 구현하는 경우에만 이러한 특성을 자동으로 구현함으로써 이를 해결합니다.
문제는 원시 포인터(*const T 및 *mut T)에서 발생합니다. 참조나 스마트 포인터와 달리, 원시 포인터는 컴파일러가 검증할 수 있는 소유권 또는 별칭 시맨틱을 갖고 있지 않습니다. 원시 포인터는 스레드 로컬 스토리지, 할당되지 않은 메모리, 또는 외부 동기화를 통해 관리되는 공유 가변 상태를 가리킬 수 있습니다. T에 기반해 원시 포인터에 무작정 Send 또는 Sync를 적용하는 것은 메모리 안전성을 위반하게 되며, 컴파일러는 포인터가 스레드 경계를 넘어 올바르게 사용된다고 보장할 수 없습니다.
해결책은 파생 논리를 이분화합니다. 집합체의 경우, 컴파일러는 구조적 재귀를 수행하여 모든 필드를 확인합니다. 원시 포인터의 경우, 컴파일러는 이러한 구현을 명시적으로 보류하며 이를 불투명하고 잠재적으로 안전하지 않은 핸들로 간주합니다. 이는 개발자가 unsafe impl Send 또는 unsafe impl Sync를 사용하여, 컴파일러가 추론할 수 없는 스레드 안전 보장을 유지할 책임을 개인적으로 져야 하도록 강요합니다.
use std::ptr::NonNull; // 집합체 유형 struct Container<T> { data: Vec<T>, // Vec<T>는 T가 Send인 경우 Send입니다. index: usize, } // Container<T>는 T: Send인 경우 자동으로 Send입니다. // 원시 포인터를 가진 유형 struct Node<T> { value: T, next: *mut Node<T>, // 원시 포인터가 자동 파생을 방해합니다. } // 명시적 옵트인이 필요합니다. unsafe impl<T: Send> Send for Node<T> {} unsafe impl<T: Sync> Sync for Node<T> {}
저는 고주파 거래 응용 프로그램을 위한 제로 할당 락 프리 MPMC (다중 생산자, 다중 소비자) 링 버퍼를 개발하면서, jemalloc 경쟁을 피하기 위해 노드가 미리 할당된 배열에 위치해야 했습니다. Node 구조체에는 페이로드와 다음 포인터를 형성하는 *mut Node<T>가 포함되어 있었습니다. 버퍼 핸들을 워커 스레드에 보내려 할 때, 컴파일러는 Node가 Send를 구현하지 않았기 때문에 코드를 거부했습니다. 노드는 오직 원자적 비교 및 교환 작업을 통해서만 접근됨을 알고 있었음에도 불구하고 말이죠.
세 가지 해결책을 평가했습니다. 첫째, 원시 포인터를 Box<Node<T>>로 교체하는 것이었습니다. 이는 Box가 힙 소유권과 개별 할당을 의미하여 캐시 친화적인 링 버퍼를 파편화시키고 HFT에서는 용납할 수 없는 할당 대기 시간을 유발하기 때문에 거부되었습니다. 둘째, NonNull<Node<T>>를 AtomicPtr로 감싸서 사용하는 것이었습니다. AtomicPtr 자체는 T가 Send인 경우 Send가 되지만, 포함된 Node 구조체는 여전히 원시 포인터 안에 있는 원시 포인터 때문에 자동 파생에 실패했습니다.(원시 포인터를 감싸는 래퍼인 NonNull이 구조적 검사를 차단합니다.) 셋째, unsafe impl 블록을 사용하여 Send와 Sync를 수동으로 구현하는 것이었습니다.
저는 next 포인터에 대한 모든 접근이 별도의 상태 인덱스에서 SeqCst 원자적 작업으로 보호됨을 공식적으로 확인한 후 세 번째 접근 방식을 선택했습니다. 이는 데이터 경합을 방지하는 happens-before 관계를 보장했습니다. 이 솔루션은 락 프리 제로 할당 아키텍처를 유지하면서 Rust의 타입 시스템을 충족했습니다. 결과적으로, 뮤텍스 오버헤드 없이 초당 수백만 개의 이벤트를 처리할 수 있는 프로덕션 그레이드 큐를 얻었지만, 미래의 유지 보수를 위해 광범위한 SAFETY 주석이 필요했습니다.
왜 Send 유형에 대한 원시 포인터가 자동으로 Send를 구현하지 않나요?
후보자들은 종종 Send가 원시 포인터를 포함한 모든 필드를 통해 "전이적"이라고 가정합니다. 그들은 원시 포인터가 고유한 소유권 시맨틱을 가지지 않는 기본 유형이라는 것을 인식하지 못합니다. 컴파일러는 스레드 로컬 스토리지에 대한 포인터와 공유 힙 메모리에 대한 포인터를 구별할 수 없으며, 별칭 규칙을 검증할 수도 없습니다. 따라서 *const T 및 *mut T는 T에 관계없이 Send 또는 Sync를 자동으로 구현하지 않으며, 프로그래머는 포인터의 스레드 안전 계약에 대한 책임을 지기 위해 unsafe impl을 사용해야 합니다.
안전하지 않은 내부를 포함하는 제네릭 구조체에 대해 Send를 조건적으로 어떻게 구현할 수 있나요?
많은 개발자들은 unsafe impl이 무조건적이어야 한다고 가정합니다. 실제로는 unsafe impl<T> Send for MyType<T> where T: Send + 'static {}와 같이 작성할 수 있습니다. 이는 내용물이 Send일 때만 Send해야 하는 제네릭 컨테이너(예: 사용자 정의 UnsafeCell 래퍼)에 필수적입니다. 후보자들은 unsafe impl의 where 절이 안전 특성과 동일한 표현력을 허용하여 스레드 안전성 제약이 제네릭 코드 전반에 걸쳐 올바르게 전파되도록 하면서 구현을 과도하게 제약하지 않는다는 점을 놓칩니다.
원시 포인터를 가진 유형에 대해 Sync와 Send를 구현하는 데 있어 안전성 요구 사항의 차이는 무엇인가요?
Send는 값의 소유권을 스레드 경계를 넘어 전송하는 것이 안전하다는 것만을 요구합니다. 원시 포인터의 경우, 이는 일반적으로 pointee가 Send일 경우 주소 값을 이동하는 것이 안전하다는 것을 의미합니다. 그러나 Sync는 스레드를 넘어서 불변 참조(&Self)를 공유하는 것이 안전해야 한다고 요구합니다. 만약 &Node가 원시 포인터 값을 노출하고(역참조할 수 있는) 다른 스레드가 가변 참조를 통해 pointee를 변경하면, 이는 데이터 경합을 구성합니다. 따라서 원시 포인터를 포함한 유형에 대한 Sync 구현은 거의 항상 동기화된 접근을 증명해야 하며(예: 포인터는 오직 Mutex 아래에서만 접근되거나 원자적 작업을 통해 접근될 수 있습니다), 반면 Send는 고유 소유권 이전의 증명만 요구할 수 있습니다.