Risposta alla domanda.
Prima di Swift 5.5, la concorrenza si basava su Grand Central Dispatch (GCD) e gestione manuale dei thread, che portava frequentemente a condizioni di competizione e corruzione della memoria a causa di uno stato mutabile condiviso non protetto. Swift ha introdotto la concorrenza strutturata con gli Actor per fornire garanzie di isolamento, ma il compilatore aveva bisogno di un meccanismo per garantire che i valori passati tra questi domini isolati fossero intrinsecamente sicuri per i thread. Questo ha portato al protocollo Sendable, che segna i tipi come sicuri da condividere attraverso i confini concorrenti imponendo la semantica di valore o la sincronizzazione interna a livello di tipo.
Quando un Actor riceve un valore da fuori del suo dominio di isolamento, quel valore potrebbe potenzialmente essere un tipo di riferimento condiviso con altri contesti di esecuzione, consentendo mutazioni simultanee che violano la sicurezza della memoria. Gli approcci tradizionali si basano su blocchi a tempo di esecuzione o mutex per proteggere le sezioni critiche, ma questi introducono sovraccarichi, rischi di stallo e sono soggetti a errori umani durante l'implementazione. La sfida era progettare un'astrazione a costo zero che verificasse staticamente la sicurezza dei thread a tempo di compilazione, mantenendo le caratteristiche di prestazione e ergonomia di Swift.
Il compilatore di Swift richiede la conformità a Sendable per tutti i tipi passati oltre i confini degli Actor, utilizzando l'analisi statica per verificare la sicurezza senza sovraccarico a tempo di esecuzione. I tipi valore come struct ed enum sono implicitamente Sendable perché presentano una semantica di valore e utilizzano ottimizzazioni di copia su scrittura per prevenire stati mutabili condivisi. Per i tipi di riferimento (class), il compilatore richiede la conformità esplicita a Sendable, imponendo che la classe sia final e contenga solo proprietà Sendable, garantendo così uno stato immutabile o internamente sincronizzato che non può essere corrotto da accessi concorrenti.
// Struct Sendable implicita struct UserData: Sendable { let id: UUID let score: Int } // Classe finale Sendable esplicita con stato immutabile final class Configuration: Sendable { let apiEndpoint: String let timeout: Duration init(endpoint: String, timeout: Duration) { self.apiEndpoint = endpoint self.timeout = timeout } } actor DataProcessor { func process(_ data: UserData) async { // Sicuro: UserData è Sendable print("Processing \(data.id)") } }
Durante l'architettura di un'applicazione di trading finanziario in tempo reale, il nostro team ha implementato un PriceFeedActor responsabile dell'aggregazione dei dati di mercato da più connessioni WebSocket, che doveva ricevere payload JSON analizzati da un NetworkManager in esecuzione su un thread in background. Inizialmente, abbiamo usato una classe di riferimento MarketData per evitare di copiare grandi set di dati durante aggiornamenti ad alta frequenza, ma il compilatore di Swift ci ha impedito di passare questi oggetti direttamente all'Actor perché non avevano la conformità a Sendable e contenevano dizionari mutabili per la memorizzazione delle elaborazioni. Questo ci ha costretto a riprogettare il nostro modello di dati per mantenere le garanzie di isolamento dell'Actor senza sacrificare il throughput richiesto per decisioni di trading sub-millisecondo.
Abbiamo rifattorizzato MarketData in uno struct contenente uno storage privato per i grandi buffer di byte e abbiamo utilizzato i meccanismi di copia su scrittura di Swift tramite ManagedBuffer per condividere lo storage sottostante fino a quando non è avvenuta la mutazione. Questo approccio ha fornito una conformità a Sendable implicita automaticamente, garantendo sicurezza a tempo di compilazione minimizzando la duplicazione della memoria durante operazioni ad alta lettura. Tuttavia, la complessità di implementare la logica manuale di copia su scrittura ha introdotto un sovraccarico di manutenzione, e abbiamo rischiato una degradazione delle prestazioni se il comportamento automatico di copia si fosse attivato inaspettatamente durante le operazioni di scrittura nel percorso caldo.
Abbiamo mantenuto il tipo di riferimento MarketData ma lo abbiamo ristrutturato come una final class con esclusivamente costanti let e proprietà Sendable profondamente immutabili, consentendoci di condividere un'unica istanza di sola lettura tra più Actors senza condizioni di competizione. Questo ha preservato l'efficienza della semantica di riferimento per grandi set di dati ed ha eliminato completamente il sovraccarico di copia, ma ha richiesto una ristrutturazione della nostra strategia di memorizzazione nella cache per utilizzare uno stato mutabile isolato dagli Actor piuttosto che mutate interne delle classi. Il cambiamento architettonico ha richiesto una significativa rifattorizzazione del nostro livello di caching per spostare lo stato mutabile in Actors dedicati, aumentando la complessità del codice ma assicurando rigorose garanzie di isolamento.
Come misura temporanea per le classi collegate a Objective-C legacy che non potevano essere immediatamente riprogettate, le abbiamo contrassegnate con @unchecked Sendable per sopprimere gli avvisi del compilatore durante la verifica manuale della sicurezza dei thread attraverso blocchi interni. Ciò ha consentito una rapida migrazione al nuovo modello di Actor, ma ha effettivamente disabilitato le garanzie statiche di Swift e reintrodotto il rischio di condizioni di competizione a tempo di esecuzione se la nostra logica di sincronizzazione manuale conteneva errori. Di conseguenza, abbiamo ristretto questo approccio solo a un'infrastruttura di log non critica, evitando di usarlo per dati finanziari di produzione dove la sicurezza era fondamentale.
Abbiamo adottato l'approccio struct per dati di streaming ad alta frequenza utilizzando progetti ottimizzati con copia su scrittura, mentre abbiamo riservato l'approccio class immutabile per oggetti di configurazione statici a cui accedevano più Actors simultaneamente. Questo approccio ibrido ha eliminato tutti i crash da condizioni di competizione rilevati durante i test di stress, riducendo i nostri rapporti di bug relativi alla concorrenza del 94% rispetto all'architettura precedente basata su GCD. I controlli a tempo di compilazione di Sendable hanno catturato tre potenziali condizioni di competizione durante lo sviluppo che avrebbero potuto causare crash intermittenti in produzione nel precedente sistema di blocco manuale.
Perché un tipo conforme a Sendable fallisce ancora nella compilazione quando viene catturato da una chiusura passata a un Task async, e come risolve questa ambiguità l'attributo @Sendable sulle chiusure?
Sebbene un tipo possa essere Sendable, le chiusure in Swift catturano variabili per riferimento per impostazione predefinita, il che potrebbe consentire successive mutazioni della variabile catturata dopo che la chiusura è stata inviata a un altro Actor. L'attributo di chiusura @Sendable limita le catture a valori Sendable e impone che la chiusura stessa non esca in modo non sicuro dal dominio concorrente. Ciò garantisce che la chiusura e tutto il suo stato catturato mantengano garanzie di isolamento attraverso i confini degli Actor, prevenendo l'introduzione di condizioni di competizione attraverso elenchi di cattura mutabili nelle operazioni asincrone.
Come influisce il rigido controllo della concorrenza di Swift 6 sugli header di Objective-C importati implicitamente, e quali meccanismi consentono la continua interoperabilità con framework legacy privi di annotazioni Sendable?
Swift 6 introduce un controllo rigido della concorrenza che tratta la maggior parte dei tipi di Objective-C come non Sendable per impostazione predefinita a causa della loro incapacità di fornire garanzie di sicurezza statiche. Gli sviluppatori devono utilizzare dichiarazioni di importazione @preconcurrency per adottare gradualmente i controlli di sicurezza o annotare manualmente gli header di Objective-C con macro SWIFT_SENDABLE. Queste annotazioni consentono al compilatore di distinguere tra oggetti legacy thread-safe e quelli che richiedono confini di isolamento, permettendo l'interoperabilità senza compromettere la sicurezza del codice pure Swift.
Qual è la differenza fondamentale tra metodi non isolati all'interno di un Actor e tipi Sendable, e quando chiamare un metodo non isolato su un'istanza di classe mutabile introduce comportamenti indefiniti?
I metodi non isolati consentono l'accesso sincrono ai dati di un Actor da fuori del suo contesto di isolamento, ma vengono eseguiti sull'executor del chiamante piuttosto che sull'executor seriale dell'Actor. Questo richiede che il metodo non acceda direttamente allo stato mutabile dell'Actor, poiché farlo bypasserebbe le garanzie di isolamento dell'Actor. Quando applicati a un tipo di riferimento mutabile che non è Sendable, i metodi non isolati possono introdurre condizioni di competizione se accedono a stati mutabili condivisi senza una corretta sincronizzazione, portando a corruzione della memoria o comportamenti indefiniti.