Arc::make_mut는 먼저 Arc가 할당에 대한 유일한 강한 참조를 보유하고 있는지 확인하여 내부 데이터에 대한 가변 접근을 제공하려고 합니다. 이 확인은 강한 참조 수에 대해 Acquire 순서로 원자적 로드를 사용하여 수행됩니다. 카운트가 정확히 1이면 작업이 진행되어 가변 참조를 반환하고, 그렇지 않으면 내부 데이터를 복제하고 Arc를 새 할당을 가리키도록 업데이트합니다.
use std::sync::Arc; let mut data = Arc::new(5); *Arc::make_mut(&mut data) += 1; // 공유되는 경우에만 복제
Acquire/Release 짝이 중요한 이유는 다른 스레드가 자신의 Arc를 떨어뜨릴 때 카운트에 대해 Release 감소를 수행하기 때문입니다. make_mut의 Acquire 로드는 감소 이전에 떨어뜨린 스레드가 수행한 모든 메모리 쓰기가 현재 스레드에 보이도록 보장하여 내부 데이터에 대한 데이터 경쟁을 방지합니다.
구성 업데이트가 Arc<Config>를 통해 전파되는 고처리량 메트릭 집계 서비스를 고려하십시오. 수천 개의 스레드가 현재 설정을 읽기 위해 참조를 보유하지만, 관리 스레드는 주기적으로 서비스를 재시작하지 않고 임계값을 조정해야 합니다.
단순한 접근 방식은 Config를 RwLock으로 감싸고 읽을 때마다 잠금을 걸거나 모든 경미한 업데이트에 대해 구조를 완전히 복제하는 것입니다. 첫 번째 솔루션은 캐시 라인 바운싱과 잠금 오버헤드로 고통받고, 두 번째는 실제로 고유한 구성이 있을 때 불필요한 할당에서 메모리와 CPU 주기를 낭비합니다.
대안은 잠금 없는 업데이트를 위해 해저드 포인터가 있는 AtomicPtr를 사용하는 것이지만, 이 경우 복잡한 수동 메모리 관리가 필요하고 오류가 발생하기 쉽습니다. 또 다른 옵션은 포인터 자체의 원자적 교환을 허용하는 RwLock<Arc<Config>>를 사용하는 것이지만, 이는 포인터 교환에 대해 추가 간접참조와 잠금을 추가합니다.
팀은 일반적인 경우를 최적화하는 Arc::make_mut를 선택했습니다: 다른 스레드가 참조를 보유하지 않으면(강한 카운트가 1임) 관리 스레드는 할당 없이 데이터에 인라인 수정합니다. 구성이 공유되어 있으면 투명하게 복제됩니다. 이는 마지막 다른 독자가 자신의 Arc를 떨어뜨릴 때(Release 사용) 관리 스레드의 후속 검사가(Acquire 사용) 모든 이전 쓰기를 보도록 보장하는 엄격한 Acquire/Release 의미가 필요합니다. 그 결과는 낮은 점유율에서 구성 업데이트에 대한 대기 시간 40% 감소였습니다.
왜 Arc::make_mut에서 참조 카운트 확인을 위해 Relaxed 순서를 사용할 수 없는가?
Relaxed 작업은 발생 보장(happens-before) 보장을 제공하지 않습니다. 만약 make_mut이 강한 카운트가 1인지 확인하기 위해 Relaxed를 사용했다면, 현재 스레드는 다른 스레드의 쓰기를 관찰하기 전에 카운트 감소를 관찰할 수 있습니다. 이는 현재 스레드가 데이터를 수정하는 동안 다른 스레드가 여전히 논리적으로 이를 읽고 있는 상황을 초래하여 데이터 경쟁을 발생시킵니다. Acquire는 카운트가 1에 도달했을 때(다른 스레드의 드롭에서 Release를 통해 동기화됨) 데이터에 대한 모든 이전 쓰기를 보도록 보장합니다.
**수동으로 **.clone()으로 Arc를 복제한 후 수정하는 것과 Arc::make_mut의 행동이 어떻게 다릅니까?
수동 복제는 동일한 할당을 가리키는 새 Arc를 생성하고, 강한 카운트를 최소한 2로 증가시킵니다. 이 새 Arc를 통해 내부 데이터에 대한 가변 접근을 얻을 수 없습니다. 왜냐하면 Arc는 오직 불변 공유만 제공하기 때문입니다. Arc::make_mut는 카운트가 1인지 확인하기 때문에 특별합니다; 그렇다면 기존 할당에 대해 &mut T를 제공합니다. 그렇지 않으면 data를 강한 카운트가 1인 새 할당으로 복제하여 원래 공유 데이터를 불변으로 유지하면서 새 복본에 대한 고유 소유권을 보장합니다.
약한 포인터(Arc::downgrade)는 Arc::make_mut의 유일성 보장에 어떻게 영향을 미칩니까?
약한 포인터는 강한 참조 카운트에 참여하지 않습니다. Arc::make_mut는 강한 카운트만 확인하고 약한 참조는 무시합니다. 그러나 약한 포인터는 할당이 여전히 존재하는 경우 강한 포인터로 업그레이드할 수 있습니다. make_mut이 인라인 수정을 진행하고(강한 카운트가 1임), 다른 스레드가 이후에 약한 포인터를 업그레이드하면 그 업그레이드는 동일한 수정된 데이터를 가리키는 새 Arc를 생성하게 됩니다. 이는 업그레이드가 수정 이후에 발생하기 때문에 안전하며, Rust의 메모리 모델은 업그레이드된 포인터가 완전히 수정된 값을 보도록 보장합니다. 약한 카운트는 수정을 방지하지 않지만 모든 강한 참조가 일시적으로 떨어져도 할당이 살아 있도록 유지합니다.