Tarihçe. ManuallyDrop<T>, Rust 1.20'de otomatik yok edici çağrısını engellemek için açıkça tasarlanmış bir sıfır maliyet sarıcı olarak ortaya çıktı. Bu, kısmen başlatılmış verilerle çalışırken veya karmaşık konteyner türlerini uygularken mem::forget'e daha güvenli ve daha anlamlı bir alternatif sunar. MaybeUninit<T>'ten farklı olarak, ManuallyDrop, iç değerin her zaman tam olarak başlatılmış olduğunu varsayar, ancak yok etme zamanlamasını programcının takdirine bırakır. Bu ayrım, koleksiyon türleri için özel Drop özellikleri uygulanırken kritik öneme sahiptir, çünkü ManuallyDrop, yok etme sırasında alan bazında çıkarım yapılmasına izin verir ve iki kat düşme hatalarını tetiklemez ya da Option<T>'nin çalışma zamanı aşamasını gerektirmez.
Problem. Standart Drop uygulamalarının, değerleri self içinden hareket ettiremeyeceği bir durumda bir genel konteynerin yok edicisi sırasında elemanları boşaltması veya yerinde inşa sırasında bir panikten kurtulması gerekir; derleyici, Drop uygulaması tamamlandıktan sonra taşınan yerin düşmesini hala deneyecektir. Option<T> kullanarak take() işlemi güvenli bir alternatif sunar, ancak çalışma zamanı aşaması (ayırt edici boolean) ortaya çıkarır ve T'nin başlangıçta bir Option olarak inşa edilmesini gerektirir ve sıfır maliyetli soyutlama ilkelerini ihlal eder. ManuallyDrop, T'nin kendisi ile aynı bellek düzenine sahip bir derleme zamanı garantili sarıcı sunar, doğrudan alan çıkarımına ptr::read ile izin verir, ek alan tahsisi veya dallanma cezaları olmaksızın.
Çözüm. Sarıcı, #[repr(transparent)] niteliği aracılığıyla T'nin yok edicisinin otomatik çağrılmasını devre dışı bırakır ve yok edicileri çalıştırmak için açıkça tehlikeli çağrılar yapılmasını gerektirir. Yığın üzerinde tahsis edilmiş kaynaklar içeren bir yapı için Drop uygularken, hassas alanları ManuallyDrop içinde sararak iç değerin çıkarımına ve ardından manuel temizliğe izin verirsiniz. drop çağrıldıktan sonra iç değere erişmek, değerin mantıksal olarak başlatılmamış hale gelmesi nedeniyle anında tanımsız davranış oluşturur; bu, hafızada kalmaya devam etmesine rağmen geçersiz göstericiler içerebilir, eğer T yığın belleğe sahipti. Bu desen, sıfır maliyetli soyutlamalar için önemlidir, çünkü Vec::drop yedek depolamayı serbest bırakmalı ve çıkarım başarısız olursa eleman düşmelerini engellemelidir.
use std::mem::ManuallyDrop; use std::ptr; struct Buffer<T> { // Yığın tahsisine ham gösterici ptr: *mut T, // ManuallyDrop, otomatik olarak düşmeden Vec'i almamıza olanak tanır temp_storage: ManuallyDrop<Vec<T>>, } impl<T> Drop for Buffer<T> { fn drop(&mut self) { // ManuallyDrop'tan Vec'i güvenli bir şekilde çıkar let vec = unsafe { ptr::read(&*self.temp_storage) }; // İki kat düşmeyi önlemek için manuel düşme gereklidir unsafe { ManuallyDrop::drop(&mut self.temp_storage) }; // Artık vec'i kullanabiliriz, derleyici self.temp_storage'i tekrar düşürmeye çalışmaz drop(vec); } }
Problem tanımı. 128KB RAM'e sahip bir mikrodenetleyici üzerinde çalışan yüksek performanslı bir kilitsiz kuyruk geliştirirken, kuyruk Drop uygulaması sırasında kritik bir sorunla karşılaştık. Kuyruk bir müdahaleci bağlı liste kullanıyordu; düğümlerin Box<Node<T>> gösterici içerdiği ve 10,000'den fazla düğümü standart Drop uygulamalarına başvurmadan boşaltmamız gerektiği gibi durumlar yaşandı (bu, kısıtlı ortamımızda yığın taşmasına yol açardı). Ayrıca, bazı düğümler, eşzamanlı bir push işlemi sırasında bir panik meydana geldiğinde ara bir başlatma durumunda olabilirdi; bu, yalnızca tamamen başlatılmış düğümlerin imha edilmesi gerektiği anlamına geliyordu.
Çözüm 1: Option ve take kullanma. Başlangıçta, her düğüm göstericisini Option<Box<Node<T>>> içinde sardık ve while let Some(node) = head.take() kullanarak listeyi boşaltmaya çalıştık. Artılar: Tamamen güvenli, idiomatik Rust, tehlikeli kod gerektirmiyor, bakımı kolay. Eksiler: Her düğüm, Option ayırt edici için ek bir byte içeriyordu, bu da gömülü bağlamımızda bellek yükünü yaklaşık %12 artırıyordu ve take() işlemi sıcak yolda bir dallanma tahmin cezası ekleyerek verimliliği %8 azalttı.
Çözüm 2: mem::forget kullanma. Tüm kuyruk yapısına std::mem::forget uygulamayı düşündük, otomatik düşmeyi önlemek için, ardından alanı serbest bırakmak için alloc::dealloc kullandık. Artılar: Tekrar eden düşmeleri önledi ve Option aşamasını atladı. Eksiler: Son derece tehlikeli, Rust'ın tahsisçi güvenlik kontrollerini atlatacak şekilde manuel bellek yönetimi gerektiriyor, manuel serbest bırakma başarısız olursa bellek sızıntısı ve ham gösterici aritmetiğine aşina olmayan gelecekteki geliştiriciler için kodu bakımsız hale getiriyor.
Çözüm 3: ManuallyDrop alanları. Node yapısını, bir sonraki göstericisini ManuallyDrop<Box<Node<T>>> olarak depolamak üzere yeniden tasarladık. Drop sırasında, listeyi ham gösterici manipülasyonu kullanarak yineledik, her bir Box'ı ptr::read aracılığıyla çıkardık, yerel bir değişkene taşıdık ve yalnızca düğümün tam olarak başlatıldığını doğruladıktan sonra çıkarılan noktada açıkça ManuallyDrop::drop çağırdık. Artılar: Sıfır bellek aşaması (ManuallyDrop #[repr(transparent)] olduğundan), yok etme sırasını tam kontrol etme, partiyelikle başlatılmış düğümleri güvenli bir şekilde handling yapma yeteneği sayesinde, başlatılmamış düğümler için manuel düşme atlayabiliyoruz. Eksiler: tehlikeli bloklar gerektiriyor ve kıdemli mühendisler tarafından invariansların dikkatlice denetlenmesi gerekiyordu.
Hangi çözüm seçildi ve neden. Çözüm 3 (ManuallyDrop) seçildi çünkü gömülü sistemin katı RAM kısıtlamaları, 10,000 düğüm kapasite gereksinimimiz için Option aşamasını kabul edilemez hale getirdi ve mem::forget üretim kodu için çok hatalıydı. ManuallyDrop, müdahale eden veri yapıları için gerekli hassas kontrolü sağlarken Rust'ın bellek güvenliği garantilerini koruma olanağı sundu. Tehlikeli işlemleri küçük, kapsamlı test edilmiş bir modüle sardık ve test derlemelerinde invariansların doğrulanmasını sağlayan debug_assertions ile belgelendirdik.
Sonuç. Kuyruk, maksimum kapasiteli zincirleri yığın taşması olmadan başarıyla yönetti, zincir uzunluğuna bakılmaksızın sabit bellek kullanımı sağladı ve tanımsız davranış olmadığını doğrulayan Miri (Orta Seviye Ara Temsilci Yorumlayıcı) testini geçerek doğrulandı. Açık manuel düşme çağrıları, imha mantığını kod gözden geçirenler için hemen görünür hale getirdi ve daha önceki C++ uygulamalarında karşılaştığımız karmaşık iki kat düşme hatalarını önledi.
Soru: ManuallyDrop<T> içindeki iç değerin ManuallyDrop::drop çağrıldıktan sonra neden mantıksal olarak erişilemez kabul edilmesi gerektiğini ve Rust derleyicisinin neden bu kısıtlamayı derleme zamanında zorunlu hale getirmediğini belirtin.
Cevap. ManuallyDrop::drop çağrıldığında, iç değer mantıksal olarak başlatılmamış bir duruma geçer, MaybeUninit'e benzer durumda. Derleyici bunu derleme zamanında zorunlu kılmamakta, çünkü ManuallyDrop, self üzerinde &mut self referansları aracılığıyla karmaşık mutasyonları zaten izin veren Drop uygulamaları gibi bağlamlarda kullanılmak üzere tasarlanmıştır. Sarıcı, belirli atomik işlem desenlerini desteklemek amacıyla, düşme işleminden sonra bile DerefMut uygulamasını kasıtlı olarak korur, bu nedenle derleyicinin tür düzeyinde "zaten düştü" gibi bir anlayışı yoktur. Düşme işleminden sonra iç değere erişmek, tanımsız davranış oluşturur, çünkü yok edici, kaynakları (yığın belleği veya dosya tanıtıcıları gibi) serbest bırakmış olabilir; bu da içindeki geçersiz göstericiler veya geçersiz bit desenleri içeren sarıcının içeride olmasına neden olur.
Soru: ManuallyDrop'ın sarılı tür T için Send ve Sync niteliği otomatik uygulamasını nasıl etkilediğini ve bunun eşzamanlı veri yapıları için neden kritik olduğunu açıklayın.
Cevap. ManuallyDrop<T>, #[repr(transparent)] niteliğini taşır; bu, T ile aynı bellek düzeni ve ABI'ye sahip olduğu ve yalnızca T uyguluyorsa Send ve Sync'i koşullu olarak uyguladığı anlamına gelir. Adaylar sıklıkla yok ediciyi bastırmanın, bir şekilde iş parçacığı güvenliği garantilerini zayıflatacağına veya UnsafeCell gibi içsel değişkenlik ekleyeceğine yanlışlıkla inanır. Gerçekte, ManuallyDrop, hiçbir senkronizasyon aşaması veya paylaşılan değişken durumu eklemediği için tüm otomatik özellik uygulamalarını korur. Bu, bir &ManuallyDrop<T>'yi iş parçacıkları arasında paylaşmanın, &T ile paylaşmakla aynı güvenlik gereksinimlerine sahip olduğu anlamına gelir; tehlike, değeri değiştirdiğinizde veya manuel düşme çağrısını yaptığınızda ortaya çıkar, bu noktada standart sahiplik kuralları ve özel değişken erişim gereklilikleri sıkı bir şekilde geçerlidir.