Historycznie, Rust wprowadził Rc (liczenie referencji) jako alternatywę skoncentrowaną na wydajności dla Arc (atomowe liczenie referencji) w scenariuszach jednowątkowych. Wczesne wersje języka nie miały tego rozróżnienia, zmuszając wszystkie współdzielone zasoby do ponoszenia kosztów operacji atomowych. Auto-traits Send i Sync zostały zaprojektowane w celu egzekwowania bezpieczeństwa wątków składniowo, co pozwala kompilatorowi automatycznie wywodzić te właściwości na podstawie składników typu.
Główny problem leży w wewnętrznej implementacji Rc, która wykorzystuje licznik nie-atomowy (typowo owinięty w Cell<usize> lub UnsafeCell<usize>) do śledzenia aktywnych referencji. Ten projekt zakłada dostęp jednowątkowy, aby uniknąć narzutu na bariery pamięci. Gdyby Rc<T> mogło implementować Send, program mógłby przenieść klon wskaźnika do innego wątku. Po zniszczeniu lub klonowaniu w nowym wątku, oba wątki wykonywałyby niesynchronizowane operacje odczytu-modyfikacji-zapisu na liczniku referencji. To stanowi wyścig danych, mogący potencjalnie skazić licznik, prowadząc do przedwczesnej dealokacji (użycie po zwolnieniu) lub wycieków pamięci (podwójne zwolnienie).
Rozwiązanie jest architektoniczne: Rc wyraźnie rezygnuje z Send i Sync poprzez posiadanie typów, które nie są bezpieczne dla wątków (lub za pomocą negatywnych implikacji w nowoczesnym Rust). To zmusza programistów do używania Arc<T> do współdzielenia między wątkami, które wykorzystuje AtomicUsize do swoich liczników, zapewniając, że operacje inkrementacji i dekrementacji są atomowe i sekwencjonowane poprawnie w całej architekturze CPU. Kompilator egzekwuje to rozróżnienie na poziomie typu, zapobiegając przypadkowemu współdzieleniu bez kontroli podczas wykonywania.
Rozważmy edytor tekstu o wysokiej wydajności analizujący dużą dokumentację w drzewo składniowe abstrakcji (AST). Parser używa Rc<Node> do reprezentowania współdzielonych podciągów (np. identyczne identyfikatory) w całym drzewie, optymalizując pamięć podczas jednowątkowej fazy analizy. Pojawia się potrzeba równoległego weryfikowania semantyki poprzez dystrybucję poddrzew do puli wątków.
Natychmiastowy problem polega na tym, że kompilacja nie udaje się, gdy próbujemy przesłać Rc<Node> do wątków roboczych. Rozważono kilka rozwiązań:
Globalna wymiana na Arc: Zastąpienie wszystkich instancji Rc przez Arc. Zalety: Minimalne zmiany w kodzie i natychmiastowe bezpieczeństwo wątków. Wady: Profilowanie ujawniło spadek wydajności o 12-15% podczas analizy z powodu zbędnych operacji atomowych w krytycznej ścieżce, naruszając budżety wydajności.
Głębokie klonowanie do transmisji: Serializacja poddrzew do Vec<u8>, wysyłanie bajtów i deserializacja na robotnikach. Zalety: Brak niebezpiecznego kodu ani zmian architektonicznych. Wady: Wysoka latencja i koszt CPU związany z przetwarzaniem złożonych struktur grafowych z wewnętrznymi cyklami, co czyni je nieopłacalnymi w edytorze czasu rzeczywistego.
Ekstrakcja wskaźnika niebezpiecznego: Transmutacja Rc do surowego wskaźnika, wysłanie wskaźnika i rekonstrukcja Rc po stronie odbiorcy. Zalety: Brak narzutu na kopiowanie. Wady: Zasadniczo niesprawdzalne; narusza invariant własności Rc (wątek odbierający nie może wiedzieć, czy wątek wysyłający porzuci swoje klony), nieuchronnie powodując skorumpowanie pamięci lub zwisające wskaźniki.
Rozsyłanie zadań przez kanały: Utrzymanie AST w wątku głównym i wysyłanie lekkich zadań walidacyjnych (zakresy bajtów lub indeksy węzłów) za pomocą kanałów crossbeam. Robotnicy zwracają wyniki bez dotykania pamięci zarządzanej przez Rc. Zalety: Zachowuje wydajność Rc podczas analizy, eliminuje wyścigi danych bez unsafe, oraz decouples komponenty. Wady: Wymaga przekształcenia algorytmu walidacji z równoległego na równolegle zadaniowy.
Zespół wybrał podejście oparte na kanałach. Parser pozostał jednowątkowy i szybki, podczas gdy walidacja skalowała się liniowo z liczbą rdzeni. Rezultatem był stabilny system bez bloków unsafe i utrzymany charakterystyki wydajności.
Dlaczego Rc<T> pozostaje !Sync nawet gdy opakowany typ T jest Sync, i jak to różni się od ograniczenia Send?
Rc<T> nie może być Sync, ponieważ immutable referencje (&Rc<T>) pozwalają na wywołanie .clone(), które modyfikuje wewnętrzny nie-atomowy licznik referencji. Nawet jeśli T sam w sobie jest bezpieczny do współdzielenia (Sync), współdzielenie opakowania Rc między wątkami pozwoliłoby na równoczesne inkrementacje licznika z wielu wątków, co spowodowałoby wyścig danych. Ograniczenie Send zapobiega przenoszeniu własności do innego wątku całkowicie, podczas gdy ograniczenie Sync uniemożliwia współdzielenie referencji między wątkami. Rc narusza obie zasady, ponieważ jego "operacje tylko do odczytu" (klonowanie) faktycznie wykonują wewnętrzną mutację.
*Jak PhantomData<T> wpływa na automatyczne wywodzenie Send i Sync dla niestandardowej struktury owiniętej surowym wskaźnikiem (const T), i dlaczego jego uwzględnienie jest krytyczne?
Bez PhantomData struktura zawierająca *const T nie niesie żadnej informacji typowej łączącej ją z T w celu wywodzenia auto-traitów. Kompilator ostrożnie zakłada, że wskaźnik może być zwieszony, aliasować dowolnie lub wskazywać na dane lokalne dla wątków i w związku z tym odmawia wywnioskowania Send lub Sync. Dodając PhantomData<T>, programista sygnalizuje kompilatorowi, że struktura logicznie posiada T. W konsekwencji, struktura automatycznie implementuje Send, jeśli T: Send, oraz Sync, jeśli T: Sync, przywracając kompozycyjne bezpieczeństwo wątkowe niezbędne dla opakowań FFI lub niestandardowych wskaźników inteligentnych.
Pod jakimi konkretnymi warunkami obiekt typu cechy Box<dyn Trait> traci auto-traity Send, nawet gdy podległy konkretny typ implementuje Send?
Obiekt cechy dyn Trait implementuje Send tylko wtedy, gdy definicja cechy wyraźnie wymaga Send jako super-wiązań (np. cecha Trait: Send). Kiedy zanikamy konkretnego typu w obiekt cechy, kompilator odrzuca wszystkie konkretne informacje typowe, w tym implementacje auto-traitów. Dopóki sama cecha nie zapewnia gwarancji Send, kompilator nie może potwierdzić, że vtable wskazuje na metody bezpieczne dla wątków. To zapobiega wysyłaniu obiektów cechy zapakowanych przez granice wątków, chyba że granica cechy wyraźnie zawiera Send (i Sync), skutecznie ograniczając bezpieczeństwo obiektów do implementacji bezpiecznych dla wątków.