Rust wprowadza auto cechy—takie jak Send i Sync—aby rozwiązać ergonomiczne obciążenie ręcznego udowadniania bezpieczeństwa wątków dla każdego typu złożonego. Historycznie programiści systemowi musieli oznaczać każdą strukturę złożonymi kontraktami współbieżności, co było podatne na błędy i nieczytelne. Kompilator rozwiązuje to poprzez automatyczne wdrażanie tych cech dla typów agregatowych (struktur, enumów, krotek), jeśli oraz tylko jeśli wszystkie ich składowe pola je implementują.
Problem pojawia się z wskaźnikami surowymi (*const T i *mut T). W przeciwieństwie do referencji lub inteligentnych wskaźników, wskaźniki surowe nie mają żadnych semantyk własności ani aliasowania, które kompilator mógłby zweryfikować. Mogą one wskazywać na lokalną przestrzeń pamięci wątku, nieprzydzieloną pamięć lub współdzielony zmienny stan zarządzany przez zewnętrzną synchronizację. Ślepe stosowanie Send lub Sync do wskaźników surowych wyłącznie na podstawie T naruszyłoby bezpieczeństwo pamięci, ponieważ kompilator nie może zagwarantować, że wskaźnik jest używany poprawnie przez granice wątków.
Rozwiązanie dzieli logikę pochodzenia. Dla agregatów kompilator wykonuje rekurencję strukturalną: sprawdza każde pole. Dla wskaźników surowych kompilator wyraźnie wstrzymuje te implementacje, traktując je jako nieprzejrzyste, potencjalnie niebezpieczne uchwyty. Zmusza to deweloperów do użycia unsafe impl Send lub unsafe impl Sync, biorąc na siebie osobistą odpowiedzialność za utrzymanie gwarancji bezpieczeństwa wątków, których kompilator nie może wywnioskować.
use std::ptr::NonNull; // Typ agregatowy struct Container<T> { data: Vec<T>, // Vec<T> jest Send, jeśli T jest Send index: usize, } // Container<T> jest automatycznie Send, jeśli T: Send // Typ z wskaźnikiem surowym struct Node<T> { value: T, next: *mut Node<T>, // Wskaźnik surowy łamie automatyczne pochodzenie } // Wymagane wyraźne opt-in unsafe impl<T: Send> Send for Node<T> {} unsafe impl<T: Sync> Sync for Node<T> {}
Podczas opracowywania bufora pierścieniowego MPMC (multi-producer, multi-consumer) bez alokacji, bez blokad do zastosowania w handlu wysokotaktowym, potrzebowałem, aby węzły znajdowały się w wstępnie przydzielonej tablicy, aby uniknąć kontencji jemalloc. Struktura Node zawierała ładunek i wskaźnik *mut Node<T> tworzący inwazyjną listę jednokierunkową. Po próbie wysłania uchwytu bufora do wątku roboczego, kompilator odrzucił kod, ponieważ Node nie implementował Send, mimo że wiedziałem, że węzły były dostępne tylko za pomocą operacji porównania i zamiany atomowej.
Oceniałem trzy rozwiązania. Po pierwsze, zastąpienie wskaźnika surowego Box<Node<T>>. Zostało to odrzucone, ponieważ Box implikuje własność sterty i pojedyncze alokacje, co fragmentowało przyjazny dla pamięci bufor ringowy i wprowadzało nieakceptowalne opóźnienia w przydzielaniu w HFT. Po drugie, użycie NonNull<Node<T>> owiniętego w AtomicPtr. Chociaż AtomicPtr sam w sobie jest Send, jeśli T jest Send, struktura Node nadal nie spełniała automatycznego pochodzenia, ponieważ wskaźnik surowy wewnątrz NonNull (który jest wrapperem wokół wskaźnika surowego) zablokował sprawdzenie strukturalne. Po trzecie, ręczna implementacja Send i Sync za pomocą bloków unsafe impl.
Wybrałem trzecie podejście po formalnym zweryfikowaniu, że wszystkie dostępy do wskaźnika next były chronione przez operacje atomowe SeqCst na osobnym indeksie stanu, co zapewniało, że relacje zachodzą przed eliminowały wyścigi danych. To rozwiązanie zachowało architekturę bez blokad, bez alokacji omijając wymagania systemu typów Rust. Rezultatem była kolejka gotowa do produkcji, zdolna do przetwarzania milionów zdarzeń na sekundę bez narzutu mutexu, choć wymagała obszernej dokumentacji SAFETY dla przyszłych konserwatorów.
Dlaczego wskaźnik surowy typu Send nie implementuje automatycznie Send?
Kandydaci często zakładają, że Send jest „transitive” przez wszystkie pola, w tym wskaźniki surowe. Nie zdają sobie sprawy, że wskaźniki surowe są typami prymitywnymi bez wewnętrznych semantyk własności. Kompilator nie może odróżnić wskaźnika do lokalnej pamięci wątku od wskaźnika do współdzielonej pamięci sterty, ani nie może zweryfikować reguł aliasowania. W konsekwencji, *const T i *mut T nigdy automatycznie nie implementują Send lub Sync, niezależnie od T, zmuszając programistę do użycia unsafe impl, aby wziąć odpowiedzialność za kontrakt bezpieczeństwa wątków.
Jak mogę warunkowo wdrożyć Send dla ogólnej struktury zawierającej niebezpieczne wewnętrzne elementy?
Wielu programistów zakłada, że unsafe impl musi być bezwarunkowe. W rzeczywistości, możesz napisać unsafe impl<T> Send for MyType<T> where T: Send + 'static {}. Jest to podstawowe dla ogólnych kontenerów (jak własny wrapper UnsafeCell), które powinny być tylko Send, gdy ich zawartość jest. Kandydaci nie dostrzegają, że klauzula where w unsafe impl zapewnia tę samą moc wyrażeniową co bezpieczne cechy, zapewniając, że ograniczenia bezpieczeństwa wątków propagują się prawidłowo przez kod ogólny, nie ograniczając nadmiernie implementacji.
Co odróżnia wymagania dotyczące bezpieczeństwa dla implementacji Sync od Send w typie z wskaźnikami surowymi?
Send wymaga jedynie, aby transfer własności wartości przez granice wątków był bezpieczny. W przypadku wskaźnika surowego oznacza to zazwyczaj, że przeniesienie wartości adresu jest bezpieczne, jeśli punktem jest Send. Sync, z kolei, wymaga, aby dzielenie niemutowalnych referencji (&Self) przez wątki było bezpieczne. Jeśli &Node ujawnia wartość wskaźnika surowego (którą można zdereferencjonować), a inny wątek modyfikuje punkt przez referencję mutowalną, to stanowi to wyścig danych. Dlatego implementacje Sync dla typów zawierających wskaźniki surowe prawie zawsze wymagają dowodu zsynchronizowanego dostępu (np. wskaźnik jest tylko dostępny w ramach Mutex lub przez operacje atomowe), podczas gdy Send może wymagać jedynie dowodu unikalnego transferu własności.