Storicamente, Rust ha introdotto Rc (conteggio dei riferimenti) come alternativa consapevole delle prestazioni a Arc (conteggio dei riferimenti atomico) per scenari unthreaded. Le versioni iniziali del linguaggio mancavano di questa distinzione, costringendo tutte le proprietà condivise a sostenere il costo delle operazioni atomiche. I trait auto Send e Sync sono stati progettati per garantire la sicurezza dei thread in modo composizionale, consentendo al compilatore di derivare automaticamente queste proprietà in base ai componenti di un tipo.
Il problema centrale risiede nell'implementazione interna di Rc, che utilizza un contatore non atomico (tipicamente racchiuso in Cell<usize> o UnsafeCell<usize>) per tracciare i riferimenti attivi. Questo design assume l'accesso unthreaded per evitare il sovraccarico delle barriere di memoria. Se Rc<T> fosse autorizzato a implementare Send, un programma potrebbe spostare una copia del puntatore a un thread diverso. Alla distruzione o clonazione nel nuovo thread, entrambi i thread effettuerebbero operazioni di lettura-modifica-scrittura non sincronizzate sul conteggio dei riferimenti. Questo costituisce una data race, potenzialmente corrompendo il conteggio, portando a deallocazioni premature (use-after-free) o perdite di memoria (double-free).
La soluzione è architetturale: Rc sceglie esplicitamente di escludere Send e Sync contenendo tipi che non sono thread-safe (o tramite implementazioni negative nel moderno Rust). Questo costringe gli sviluppatori a utilizzare Arc<T> per la condivisione tra thread, che impiega AtomicUsize per i suoi contatori, garantendo che le operazioni di incremento e decremento siano atomiche e sequenziate correttamente su tutti i core della CPU. Il compilatore applica questa distinzione a livello di tipo, prevenendo condivisioni accidentali senza controlli di runtime.
Considera un editor di testo ad alte prestazioni che analizza un grande documento in un Albero Sintattico Astratto (AST). Il parser utilizza Rc<Node> per rappresentare sottostringhe condivise (es. identificatori identici) nell'albero, ottimizzando la memoria durante la fase di parsing unthreaded. Emergerebbe la necessità di parallelizzare la validazione semantica distribuendo sotto-alberi a un pool di thread.
Il problema immediato è che la compilazione fallisce quando si tenta di inviare Rc<Node> ai thread di lavoro. Sono state valutate diverse soluzioni:
Sostituzione globale con Arc: Sostituire tutte le istanze di Rc con Arc. Pro: Modifiche minime al codice e sicurezza immediata dei thread. Contro: La profilazione ha rivelato un degrado della throughput del 12-15% durante il parsing a causa di operazioni atomiche non necessarie nel percorso caldo, violando i budget di prestazione.
Clonazione profonda per trasmissione: Serializzare sotto-alberi in Vec<u8>, inviare byte e deserializzare sui lavoratori. Pro: Nessun codice non sicuro o modifiche architetturali. Contro: Alta latenza e costo CPU per il marshalling di strutture grafiche complesse con cicli interni, rendendolo proibitivo per la modifica in tempo reale.
Estrazione di puntatori non sicuri: Trasmutare Rc in un puntatore grezzo, inviare il puntatore e ricostruire Rc sul ricevente. Pro: Overhead zero-copy. Contro: Fondamentalmente non sicuro; viola l'invariante di proprietà di Rc (il thread ricevente non può sapere se il thread mittente abbandona le sue copie), causando inevitabilmente corruzione della memoria o puntatori pendenti.
Dispatch di task basato su canali: Mantenere l'AST nel thread principale e inviare task di validazione leggeri (intervalli di byte o indici di nodi) tramite canali crossbeam. I lavoratori restituiscono risultati senza toccare la memoria gestita da Rc. Pro: Preserva le prestazioni di Rc per il parsing, elimina le data race senza unsafe e disaccoppia i componenti. Contro: Richiede una ristrutturazione dell'algoritmo di validazione da parallelo ai dati a parallelo ai task.
Il team ha scelto l'approccio basato su canali. Il parser è rimasto unthreaded e veloce, mentre la validazione si è scalata linearmente con il numero di core. Il risultato è stato un sistema stabile senza blocchi unsafe e ha mantenuto le caratteristiche di prestazione.
Perché Rc<T> rimane !Sync anche quando il tipo racchiuso T è Sync, e come si differenzia da questa restrizione di Send?
Rc<T> non può essere Sync perché i riferimenti immutabili (&Rc<T>) consentono di chiamare .clone(), il che modifica il conteggio dei riferimenti interno non atomico. Anche se T stesso è sicuro da condividere (Sync), la condivisione del wrapper Rc tra thread consentirebbe incrementi simultanei del contatore da più thread, causando una data race. La restrizione di Send impedisce di spostare completamente la proprietà a un altro thread, mentre la restrizione di Sync impedisce anche la condivisione di riferimenti tra thread. Rc viola entrambi i principi perché le sue operazioni "sola lettura" (clonazione) eseguono in realtà una mutazione interna.
*Come influisce PhantomData<T> sulla derivazione automatica di Send e Sync per una struct personalizzata che incapsula un puntatore grezzo (const T), e perché è critica la sua inclusione?
Senza PhantomData, una struct contenente *const T non porta alcuna informazione di tipo che la colleghi a T per fini di derivazione di trait automatici. Il compilatore assume con cautela che il puntatore possa pendere, fare alias in modo arbitrario, o puntare a dati locali al thread, e quindi rifiuta di inferire Send o Sync. Includendo PhantomData<T>, lo sviluppatore segnala al compilatore che la struct possiede logicamente un T. Di conseguenza, la struct implementa automaticamente Send se T: Send e Sync se T: Sync, ripristinando la sicurezza dei thread compositiva essenziale per i wrapper FFI o per puntatori intelligenti personalizzati.
In quali condizioni specifiche un oggetto trait Box<dyn Trait> perde il trait automatico Send, anche quando il tipo concreto sottostante implementa Send?
Un oggetto trait dyn Trait implementa Send solo se la definizione del trait richiede esplicitamente Send come super-bound (es. trait Trait: Send). Quando si cancella il tipo concreto in un oggetto trait, il compilatore scarta tutte le informazioni di tipo specifiche, comprese le implementazioni dei trait automatici. A meno che il trait stesso non garantisca la proprietà di Send, il compilatore non può verificare che il vtable punti a metodi sicuri per i thread. Questo impedisce l'invio di oggetti trait incapsulati oltre i confini dei thread a meno che il bound del trait non includa esplicitamente Send (e Sync), limitando efficacemente la sicurezza dell'oggetto alle implementazioni sicure per i thread.