Historia. ManuallyDrop<T> pojawił się w Rust 1.20 jako wrapper o zerowym koszcie, zaprojektowany w celu inhibitowania automatycznego wywołania destruktora, działając jako bezpieczniejsza i bardziej semantycznie klarowna alternatywa dla mem::forget przy obsłudze częściowo zainicjowanych danych lub implementacji złożonych typów kontenerów. W odróżnieniu od MaybeUninit<T>, który zarządza pamięcią, która może jeszcze nie zawierać ważnej instancji T, ManuallyDrop zakłada, że wewnętrzna wartość zawsze jest w pełni zainicjowana, ale odkłada czas jej zniszczenia na decyzję programisty. To rozróżnienie jest kluczowe przy implementacji niestandardowych cech Drop dla typów kolekcji, ponieważ ManuallyDrop pozwala na ekstrakcję pól podczas destrukcji bez wywoływania błędów podwójnego usunięcia lub wymagania narzutu czasowego Option<T>.
Problem. Rozważ scenariusz, w którym ogólny kontener musi opróżnić elementy podczas cyklu destrukcji lub odzyskać z paniki podczas konstrukcji w miejscu; standardowe implementacje Drop nie mogą przenieść wartości z self, ponieważ kompilator nadal spróbuje usunąć lokalizację, z której dokonano przeniesienia po zakończeniu implementacji Drop. Podczas gdy Option<T> z take() oferuje bezpieczną alternatywę, wprowadza narzut czasowy (boolean dyskryminacyjny) i wymaga, aby T zostało początkowo skonstruowane jako Option, naruszając zasady zerowej abstrakcji kosztów. ManuallyDrop zapewnia wrapper o gwarantowanej kompilacji z identycznym układem pamięci jak T sam w sobie, umożliwiając bezpośrednią ekstrakcję pól za pomocą ptr::read bez dodatkowej alokacji pamięci lub karności branżowej.
Rozwiązanie. Wrapper dezaktywuje automatyczne wywołanie destruktora T dzięki atrybutowi #[repr(transparent)], wymagając wyraźnego niebezpiecznego wywołania do ManuallyDrop::drop, aby uruchomić destruktory. Przykładając Drop do struktury zawierającej zasoby alokowane na stercie, należy owinąć wrażliwe pola w ManuallyDrop, co pozwala na ekstrakcję wewnętrznej wartości, a następnie ręczne czyszczenie. Dostęp do wewnętrznej wartości po wywołaniu drop stanowi natychmiastowe zachowanie niezdefiniowane, jako że wartość staje się logicznie nieinicjowana, mimo że pozostała w pamięci, mogąca potencjalnie zawierać wskaźniki wieszające, jeśli T posiadał pamięć sterty. Ten wzór jest kluczowy dla abstrahacji zerowych kosztów, takich jak Vec::drop, które muszą zwalniać pamięć zaplecza przy jednoczesnym zapobieganiu usunięciu elementów, jeśli ekstrakcja nie powiodła się z powodu przepełnień pojemności.
use std::mem::ManuallyDrop; use std::ptr; struct Buffer<T> { // Surowy wskaźnik do alokacji na stercie ptr: *mut T, // ManuallyDrop pozwala nam na wzięcie Vec bez automatycznego wywołania usunięcia temp_storage: ManuallyDrop<Vec<T>>, } impl<T> Drop for Buffer<T> { fn drop(&mut self) { // Bezpieczna ekstrakcja Vec z ManuallyDrop let vec = unsafe { ptr::read(&*self.temp_storage) }; // Ręczne usunięcie wymagane, aby zapobiec podwójnemu usunięciu Vec unsafe { ManuallyDrop::drop(&mut self.temp_storage) }; // Teraz możemy używać vec bez ingerencji kompilatora, który próbuje ponownie usunąć self.temp_storage drop(vec); } }
Opis problemu. Podczas rozwijania wydajnej kolejki bezblokującej dla wbudowanego systemu Rust działającego na mikrokontrolerze z 128KB RAM, napotkaliśmy krytyczny problem podczas implementacji Drop kolejki. Kolejka używała infiltracyjnej listy powiązanej, w której węzły zawierały wskaźniki Box<Node<T>>, a my musieliśmy opróżnić kolejkę z ponad 10 000 węzłów bez rekurencji przez standardowe implementacje Drop (co spowodowałoby przepełnienie stosu w naszym ograniczonym środowisku). Ponadto niektóre węzły mogły być w pośrednim stanie inicjalizacji podczas równoczesnej operacji push, gdy wystąpiła panika, co wymagało od nas selektywnego zniszczenia tylko w pełni zainicjowanych węzłów, podczas gdy częściowo skonstruowane byłyby „wyciekane”, aby zachować bezpieczeństwo.
Rozwiązanie 1: Użycie Option i take. Początkowo owinęliśmy każdy wskaźnik węzła w Option<Box<Node<T>>> i użyliśmy while let Some(node) = head.take() do opróżnienia listy. Zalety: Całkowicie bezpieczne, idiomatyczne Rust, nie wymaga kodu niebezpiecznego i jest łatwe do utrzymania. Wady: Każdy węzeł niósł dodatkowy bajt dla dyskryminanta Option, zwiększając obciążenie pamięci o około 12% w naszym wbudowanym kontekście, a operacja take() wprowadziła karę przewidywania gałęzi na gorącej ścieżce, co obniżyło przepustowość o 8% w testach.
Rozwiązanie 2: Użycie mem::forget. Rozważyliśmy użycie std::mem::forget dla całej struktury kolejki, aby zapobiec automatycznym usunięciom, a następnie ręcznie zwolnić pamięć przy użyciu alloc::dealloc. Zalety: Zapobiegło rekurencyjnym usunięciom i ominęło narzut Option. Wady: Ekstremalnie niebezpieczne, wymagało ręcznego zarządzania pamięcią z ominięciem kontroli bezpieczeństwa alokatora Rust, prowadząc do wycieków pamięci, jeśli ręczne uwolnienie się nie powiodło, i uczyniło kod trudnym do utrzymania dla przyszłych programistów nieznających arytmetyki wskaźników.
Rozwiązanie 3: Pola ManuallyDrop. Pr reorganizowaliśmy strukturę Node, aby przechowywać wskaźnik next jako ManuallyDrop<Box<Node<T>>>. Podczas Drop iterowaliśmy przez listę za pomocą manipulacji surowymi wskaźnikami, ekstraktowaliśmy każdy Box za pomocą ptr::read, przenosiliśmy go do lokalnej zmiennej i wyraźnie wywoływaliśmy ManuallyDrop::drop na wyekstrahowanym slocie dopiero po zweryfikowaniu, że węzeł był w pełni zainicjowany za pomocą atomowej flagi stanu. Zalety: Zerowe obciążenie pamięci (ManuallyDrop jest #[repr(transparent)]), pełna kontrola nad kolejnością zniszczenia, możliwość bezpiecznego radzenia sobie z częściowo zainicjowanymi węzłami poprzez pomijanie ręcznego usunięcia dla nieinicjowanych węzłów. Wady: Wymagało bloków unsafe oraz starannej audytu invariantów przez doświadczonych inżynierów.
Które rozwiązanie zostało wybrane i dlaczego. Wybraliśmy Rozwiązanie 3 (ManuallyDrop), ponieważ surowe ograniczenia pamięci systemu wbudowanego uczyniły naddatek Option niedopuszczalnym dla naszej wymagania 10 000 węzłów, a mem::forget było zbyt skomplikowane do kodu produkcyjnego. ManuallyDrop pozwoliło nam zachować gwarancje bezpieczeństwa pamięci Rust przy jednoczesnym zapewnieniu precyzyjnej kontroli potrzebnej dla infiltracyjnych struktur danych. Owinęliśmy operacje niebezpieczne w mały, dokładnie przetestowany moduł z debug_assertions weryfikującymi inwarianty w testowych wersjach, a zestawiliśmy inwarianty bezpieczeństwa dokładnie.
Wynik. Kolejka skutecznie obsługiwała łańcuchy o maksymalnej pojemności bez przepełnienia stosu, utrzymując stałe zużycie pamięci niezależnie od długości łańcucha, i przeszła walidację Miri (Interpreter Poziom Średni Reprezentacji Pośredniej), potwierdzając brak zachowań niezdefiniowanych. Wyraźne wywołania ręcznego usunięcia uczyniły logikę zniszczenia natychmiastowo widoczną dla recenzentów kodu, zapobiegając subtelnym błędom podwójnego usunięcia, które dręczyły wcześniejsze implementacje C++ tej samej struktury danych w dziedzicznych bazach kodu.
Pytanie: Dlaczego wewnętrzna wartość ManuallyDrop<T> musi być uważana za logicznie niedostępną po wywołaniu ManuallyDrop::drop, a dlaczego kompilator Rust nie egzekwuje tej restrykcji w czasie kompilacji?
Odpowiedź. Po wywołaniu ManuallyDrop::drop, wewnętrzna wartość przechodzi w stan logicznie nieinicjowany, identyczny do MaybeUninit przed inicjalizacją. Kompilator nie może egzekwować tego w czasie kompilacji, ponieważ ManuallyDrop został zaprojektowany do użytku w kontekstach takich jak implementacje Drop, gdzie kontroler pożyczek już zezwala na złożone mutacje self przez odniesienia &mut self. Wrapper celowo zachowuje swoją implementację DerefMut nawet po usunięciu, aby wspierać pewne wzorce operacji atomowych, co oznacza, że kompilator nie ma wbudowanego pojęcia „już usunięte” na poziomie typu. Dostęp do wewnętrznej wartości po usunięciu stanowi natychmiastowe zachowanie niezdefiniowane, ponieważ destruktor mógł zwolnić zasoby (takie jak pamięć sterty lub deskryptory plików), pozostawiając wrapper z wiszącymi wskaźnikami lub nieważnymi wzorcami bitowymi.
Pytanie: Jak ManuallyDrop wpływa na automatyczną implementację cech Send i Sync dla owiniętego typu T, i dlaczego jest to kluczowe dla współbieżnych struktur danych?
Odpowiedź. ManuallyDrop<T> nosi atrybut #[repr(transparent)], co oznacza, że ma identyczny układ pamięci i ABI do T, i warunkowo implementuje Send i Sync tylko wtedy, gdy T je implementuje. Kandydaci często błędnie wierzą, że tłumienie destruktora w jakiś sposób osłabia gwarancje bezpieczeństwa wątków lub dodaje zmienność wewnętrzną jak UnsafeCell. W rzeczywistości ManuallyDrop zachowuje wszystkie implementacje automatycznych cech, ponieważ nie wprowadza narzutu synchronizacji ani wspólnego zmiennego stanu. To implikuje, że dzielenie &ManuallyDrop<T> między wątkami ma identyczne wymagania dotyczące bezpieczeństwa, jak dzielenie &T; niewłaściwość pojawia się jedynie w przypadku modyfikacji wartości lub wywołania ręcznego usunięcia, w którym to punkcie standardowe zasady własności i wymagania dotyczące wyłącznego dostępu do mutacji mają zastosowanie ściśle.