Il modello di concorrenza di Swift ha subito un cambiamento di paradigma con Swift 5.5, introducendo la concorrenza strutturata per sostituire i modelli legacy di Grand Central Dispatch che spesso portavano a compiti orfani e perdite di risorse. Prima di questo, gli sviluppatori gestivano manualmente le istanze di DispatchGroup per tracciare il lavoro concorrente, richiedendo una sincronizzazione esplicita per prevenire condizioni di gara durante la cancellazione. L'astrazione TaskGroup è stata progettata per racchiudere nativamente l'albero delle relazioni padre-figlio, garantendo che il runtime mantenga i metadati del ciclo di vita piuttosto che lo sviluppatore.
Il problema centrale risiede nel mantenere una gerarchia deterministica in cui i compiti padre possono segnalare in modo affidabile la cancellazione a tutti i discendenti senza dover attraversare registri globali o array di riferimenti deboli manuali. Gli approcci tradizionali che utilizzano OperationQueue richiedono la registrazione e la deregistrazione esplicite dei gestori di completamento, creando una gestione dello stato fragile che fallisce se un gestore di completamento viene saltato a causa di un'uscita anticipata. Inoltre, la propagazione della cancellazione richiede un complesso polling di flag atomici, spesso portando a una reattività ritardata o a un eccessivo sovraccarico della CPU.
Swift affronta questo problema incorporando un record di compito all'interno del contesto di ciascun compito che punta al suo genitore, formando una lista collegata intrusiva radicata nel TaskGroup. Quando viene invocato addTask, il runtime inserisce un record di compito figlio in questa lista, registrandolo atomicamente con il gestore di cancellazione del padre. Il meccanismo di cancellazione utilizza una macchina a stati: quando viene chiamato cancelAll(), il runtime attraversa questa lista, impostando il flag isCancelled sui metadati di ciascun compito figlio e risvegliando gli esecutori sospesi. Questo garantisce una propagazione O(n) dove n è la profondità dell'albero, evitando blocchi globali.
import Foundation func downloadImages(urls: [URL]) async throws -> [Data] { try await withThrowingTaskGroup(of: Data.self) { group in for url in urls { group.addTask { // Il compito figlio controlla automaticamente la cancellazione del genitore let (data, _) = try await URLSession.shared.data(from: url) return data } } // Simulazione della cancellazione da parte dell'utente group.cancelAll() var results: [Data] = [] for try await data in group { results.append(data) } return results } }
Un'applicazione di elaborazione multimediale doveva generare miniature per 10.000 immagini consentendo agli utenti di annullare durante l'esecuzione. Il team di ingegneri inizialmente usava un approccio DispatchGroup, tracciando gli oggetti attivi di URLSessionDataTask in un NSHashTable thread-safe per abilitare la cancellazione.
La prima soluzione utilizzava DispatchGroup con un DispatchSemaphore per limitare la concorrenza. Sebbene fosse funzionale, richiedeva logica complessa per rimuovere i compiti completati dal set di cancellazione. Si verificavano condizioni di gara in cui i compiti si completavano tra il segnale di cancellazione e l'enumerazione del set, causando all'app di fare riferimento a oggetti deallocati. Questo approccio perdeva anche memoria quando il controller della vista veniva eliminato perché le notifiche di DispatchGroup trattenevano fortemente il delegato.
Il secondo approccio adottava FlatMap di Combine con un PassthroughSubject per la cancellazione. Questo forniva una migliore composizione ma introduceva un sovraccarico di memoria significativo a causa dell'allocazione della catena di publisher. La propagazione della cancellazione richiedeva di memorizzare i token AnyCancellable in una collezione necessitando di una pulizia manuale. L'astrazione dichiarativa nascondeva la gerarchia reale dei compiti, rendendo difficile il debug quando i segnali di cancellazione non riuscivano a propagarsi attraverso la catena degli operatori.
Il team è migrato a TaskGroup di Swift. Questo ha eliminato la gestione manuale di NSHashTable perché il runtime collegava automaticamente ciascun compito di generazione di miniature al dominio di cancellazione del gruppo. Quando l'utente premeva annulla, il controller della vista invocava group.cancelAll(), che segnalava atomicamente a tutti i compiti in esecuzione di fermarsi al loro prossimo punto di sospensione await. Questa soluzione garantiva che nessun compito orfano continuasse ad elaborare dopo la deallocazione della vista, e la scoping deterministica di withThrowingTaskGroup garantiva una pulizia automatica anche se la funzione lanciava un errore.
La latenza di cancellazione è scesa da una media di 500 ms (attendendo l'enumerazione manuale del set) a meno di 10 ms (attraversamento diretto della lista collegata). Il profilo della memoria mostrava zero oggetti Task persi dopo la cancellazione, e il codice si era ridotto di 40 righe di boilerplate di sincronizzazione.
Come gestisce TaskGroup lo scenario in cui un compito figlio ignora la cancellazione e continua a eseguire indefinitamente?
I candidati spesso credono che TaskGroup termini forzatamente i compiti o inietti eccezioni. In realtà, la cancellazione di Swift è cooperativa: il runtime imposta il flag isCancelled nel contesto del compito, ma il compito continua fino a quando non raggiunge un punto di sospensione o controlla esplicitamente Task.isCancelled. Il compito figlio deve periodicamente controllare Task.checkCancellation() o fare affidamento su API consapevoli della cancellazione. Se un compito esegue un ciclo CPU-bound stretto senza punti di sospensione, blocca indefinitamente il completamento del gruppo. Per prevenire questo, i calcoli a lungo termine dovrebbero utilizzare Task.yield() o suddividere il lavoro in blocchi controllando i flag di cancellazione.
Perché aggiungere un compito a un TaskGroup dopo aver chiamato cancelAll() risulta comunque in cancellazione immediata di quel nuovo compito?
Molti presumono che cancelAll() sia un segnale unico inviato solo ai figli esistenti. Tuttavia, l'implementazione di Swift segna il TaskGroup stesso come cancellato nel suo record di stato. Quando successivamente viene invocato addTask, il runtime controlla lo stato di cancellazione del gruppo atomicamente durante la creazione del compito; se annullato, il nuovo compito figlio viene creato con il suo flag isCancelled già impostato. Questo assicura che i compiti aggiunti in ritardo non possano sfuggire al dominio di cancellazione, mantenendo la garanzia strutturale che un ambito cancellato non possa produrre nuovi risultati validi. Questo previene condizioni di gara in cui compiti aggiunti durante il termine della cancellazione sfuggono.