질문의 역사
Rust의 초기 설계에서, 디자이너들은 중대한 교착 상태에 직면했습니다: 순환 그래프와 런타임 대여 확인된 컨테이너와 같은 필수 데이터 구조는 공유 참조를 통한 변경을 요구했으나, 이는 언어의 독점적 가변 접근이라는 기초 원칙에 정면으로 반하는 것이었습니다. 이를 타협하지 않고 해결하기 위해 UnsafeCell이 도입되었으며, 이는 공유 참조 &T와 관련된 불변성 보장의 예외를 허용하는 유일한 원시 타입으로, 모든 안전한 내부 가변성 추상화의 기반이 됩니다.
문제 설명
Rust 컴파일러는 &T의 불변성을 활용하여 값 캐싱과 명령어 재정렬과 같은 공격적인 최적화를 수행하며, 참조의 생애 동안 기본 메모리가 변하지 않는다고 가정합니다. UnsafeCell은 컴파일러에 그 내용물이 공유 참조를 통해 접근할 때도 변경될 수 있음을 알리며, 효과적으로 해당 데이터에 대한 이러한 최적화를 비활성화합니다. 그러나 이 선택은 **UnsafeCell::get()**를 통해 얻은 원시 포인터로부터 파생된 참조로 확장되지 않습니다; 이 포인터가 &mut T로 변환되는 순간, 표준 별칭 규칙이 절대적인 강도로 다시 적용됩니다.
해결책
해결책은 프로그래머가 UnsafeCell의 원시 포인터로 생성된 모든 가변 참조 &mut T가 그 생애 동안 메모리에 대한 유일한 접근 경로여야 한다는 불변성을 유지해야 한다는 것입니다. 이러한 독점성은 가변 참조의 존재 기간 동안 다른 포인터, 참조 또는 후속 get() 호출을 통한 동시 읽기 또는 쓰기를 금지합니다. UnsafeCell은 대여 검사기를 비활성화하지 않으며, 컴파일러에서 개발자로 책임을 전가하여 시간적 독점성을 보장하고 데이터 경합을 방지해야 합니다.
문제 설명
우리는 여러 스레드가 특정 금융 자산과 관련된 카운터를 업데이트하는 저지연 거래 시스템을 위한 높은 처리량의 메트릭 집계기를 설계하고 있었습니다. 초기화 후 공유 맵은 불변성이었지만, 메트릭 값은 빈번한 증가를 필요로 했습니다. **Mutex<u64>**를 사용하면 수용할 수 없는 콘텐츠가 발생했으며, AtomicU64는 복합 메트릭 유형의 복잡성을 처리하기에는 불충분했습니다. 우리는 런타임 대여 검사가 없는 구조체에 대해 잠금이 필요 없는 제로 할당 업데이트가 필요했습니다.
고려된 다른 솔루션들
솔루션 1: 샤드 뮤텍스
각 메트릭을 Mutex로 래핑하고 이를 256개의 샤드에 배포하여 콘텐츠를 감소하는 방법을 검토했습니다. 이 접근은 간단한 안전성과 유지관리가 용이한 코드를 제공했습니다. 그러나 프로파일링 결과, 비경쟁적인 Mutex 작업조차도 수백 나노초가 소요되어 futex 시스템 호출 및 캐시 일관성 프로토콜 때문에 우리의 엄격한 서브 마이크로초 지연 예산을 위반했습니다.
솔루션 2: 박스 값과 함께하는 AtomicPtr
또 다른 접근은 값을 **AtomicPtr<Metric>**로 저장하고 업데이트를 위한 비교-교환 루프를 사용하는 것이었습니다. 이는 차단을 제거했지만 매 증가마다 새로운 Box 인스턴스를 할당해야 하여 심각한 메모리 압박과 할당자 경합을 초래했습니다. 더욱이, 이는 해저드 포인터 또는 에포크 기반의 가비지 수집을 요구하는 메모리 회수의 복잡성을 증가시켜 코드 복잡성과 감사 표면적을 크게 증가시켰습니다.
솔루션 3: 캐시 라인 정렬과 함께하는 UnsafeCell
우리는 메트릭을 **UnsafeCell<Metric>**로 저장하고 캐시 라인 알라인 구조체 내에 두어 서로 다른 샤드에 쓰는 스레드가 결코 캐시 라인을 공유하지 않도록 보장했습니다. 각 스레드는 **UnsafeCell::get()**을 통해 원시 포인터를 얻고, 업데이트 중에 &mut Metric으로 캐스팅했습니다—이는 샤딩 논리를 통해 안전함을 보장하였으며, 다른 스레드가 해당 슬롯에 접근할 수 없게 했습니다—그리고 변형을 수행했습니다. 이는 unsafe 블록과 우리의 일관된 해싱이 동시 접근 시 충돌이 발생하지 않음을 보장하는 공식적인 증명이 필요했습니다.
선택된 솔루션과 그 이유
우리는 솔루션 3을 선택했습니다. 이는 원시 메모리에 대한 제로 비용 추상화를 제공하면서 공격적인 지연 요구를 충족했습니다. 샤딩 보장은 수동으로 독점 접근을 증명해 주었으며, UnsafeCell을 런타임 동기화 오버헤드 없이 활용할 수 있게 해주었습니다. 우리는 MIRI와 loom 동시성 모델 체커를 사용하여 모든 가능한 스레드 간섭 하에서 별칭 위반이 발생하지 않음을 검증했습니다.
결과
구현은 핫 경로에서 제로 할당의 100 나노초 미만 업데이트 지연을 달성했습니다. 그러나 후속 리팩토링 중 유지 관리 작업이 암묵적인 샤드 잠금을 획득하지 않고 모든 샤드를 반복하면서 같은 메트릭에 두 개의 가변 참조를 생성하는 미묘한 회귀가 발생했습니다. MIRI는 CI 중 즉시 이를 정의되지 않은 동작으로 플래그를 지정했습니다. 이는 UnsafeCell이 이론적으로 안전을 보장할 때조차도 철저한 규율을 요구함을 강화했습니다.
왜 UnsafeCell에서 파생된 두 개의 가변 참조를 동시에 보유하는 것이 정의되지 않은 동작인가?
UnsafeCell은 타입 수준에서 공유 참조의 불변성 보장을 선택적으로 제한다 하더라도, &mut T 타입 자체의 기본 불변성을 완화하지 않습니다. **get()**을 호출하면 생명주기나 별칭 제약이 없는 원시 포인터 *mut T를 받습니다. 그러나 이 포인터를 &mut T로 역참조하는 순간, 이 참조가 독점적이라고 컴파일러에 선언하는 것입니다. 같은 UnsafeCell에서 두 개의 그러한 참조를 생성하여 겹치는 메모리를 참조하는 것은 Rust의 메모리 모델의 근본적인 별칭 XOR 변형 규칙을 위반하게 되어, 해당 참조가 어떻게 구성되었든 즉각적으로 정의되지 않은 동작으로 이어집니다.
MIRI는 UnsafeCell 불변 위반을 어떻게 감지하며, 코드가 생산 테스트를 통과하지만 MIRI에서 실패할 수 있는 이유는 무엇인가?
MIRI는 추상 "태그"를 통해 메모리 접근 권한을 추적하는 Stacked Borrows(또는 선택적으로 Tree Borrows) 별칭 모델을 구현합니다. UnsafeCell로부터 참조를 생성할 때 MIRI는 고유한 태그를 할당합니다. 첫 번째 참조가 활성 상태일 때 동일한 메모리에 다른 태그로 접근하려고 시도하는 것은 위반으로 간주됩니다. 코드는 하드웨어 메모리 모델이 관대하기 때문에 종종 표준 테스트를 통과하는데, 무해한 데이터 경합이 실제로 충돌로 이어지지 않을 수 있습니다. 그러나 MIRI는 이론 모델을 엄격하게 시행하여, 적절한 동기화 없이 동일한 UnsafeCell로부터 공유 참조를 생성하여 가변 참조를 무효화하려는 위반을 잡아냅니다. 비록 현재 CPU 아키텍처에서 애셈블리가 작동한다 하더라도 말입니다.
Cell<T>가 변형을 위해 unsafe 블록을 요구하지 않는 이유와 UnsafeCell<T>가 요구하는 이유를 설명하고, 이 구별을 가능하게 하는 특정 안전 보장을 식별하시오.
**Cell<T>**는 내부 데이터를 참조로 노출하지 않음으로써 unsafe 없이 내부 가변성을 달성합니다; 복사 가능한 타입에 대해서는 값 복사(set)만 허용하고, 비 복사 타입에 대해서는 이동(replace)만 허용합니다. Cell은 절대로 포함된 값에 대한 &T 또는 &mut T를 내보내지 않으므로 별칭 규칙을 위반할 수 없습니다—별칭할 참조가 없기 때문입니다. 반면에 UnsafeCell은 원시 포인터 *mut T를 반환하는 **get()**을 제공하여 참조 생성을 허용합니다. 이 유연성은 복잡한 제자리 변형에 필요하지만, 독점성과 데이터 경합 방지를 보장하는 책임을 전적으로 프로그래머에게 전가하여 unsafe 블록을 필요로 하게 됩니다.