Das Konkurrenzmodell von Swift erlebte mit Swift 5.5 einen Paradigmenwechsel durch die Einführung strukturierter Konkurrenz, um die veralteten Grand Central Dispatch-Muster zu ersetzen, die oft zu verwaisten Aufgaben und Ressourcenlecks führten. Davor verwalteten Entwickler manuell DispatchGroup-Instanzen, um parallele Arbeiten zu verfolgen, was explizite Synchronisierung erforderte, um Rennbedingungen während der Stornierung zu vermeiden. Die TaskGroup-Abstraktion wurde entwickelt, um die Eltern-Kind-Beziehungsstruktur nativ zu kapseln, sodass die Laufzeit Lebenszyklus-Metadaten verwaltet, anstatt den Entwickler.
Das Kernproblem liegt in der Aufrechterhaltung einer deterministischen Hierarchie, in der Elternaufgaben zuverlässig die Stornierung an alle Nachkommen signalisieren können, ohne globale Register oder manuelle schwache Referenzarrays durchlaufen zu müssen. Traditionelle Ansätze mit OperationQueue erforderten die explizite Registrierung und Deregistrierung von Abschluss-Handlern, was ein fragiles Zustandsmanagement schuf, das scheiterte, wenn ein Abschluss-Handler aufgrund eines frühen Ausstiegs übersprungen wurde. Darüber hinaus erfordert die Propagation der Stornierung komplexes atomares Flaggen-Abfragen, das häufig zu verzögerter Reaktionsfähigkeit oder übermäßigem CPU-Overhead führt.
Swift adressiert dies, indem es einen Aufgabenaufzeichnung innerhalb des Kontexts jeder Aufgabe einbettet, die auf die Eltern verweist und so eine intrusive verkettete Liste bildet, die an der TaskGroup verwurzelt ist. Wenn addTask aufgerufen wird, fügt die Laufzeit einen untergeordneten Aufgabenaufzeichnung in diese Liste ein und registriert sie atomar mit dem Stornierungs-Handler des Elternteils. Der Stornierungsmechanismus verwendet eine Zustandsmaschine: Wenn cancelAll() aufgerufen wird, durchläuft die Laufzeit diese Liste, setzt das isCancelled-Flag in den Metadaten jeder untergeordneten Aufgabe und weckt angehaltene Executor. Dies gewährleistet eine O(n)-Propagation, wobei n die Baumtiefe ist, und vermeidet globale Sperren.
import Foundation func downloadImages(urls: [URL]) async throws -> [Data] { try await withThrowingTaskGroup(of: Data.self) { group in for url in urls { group.addTask { // Unteraufgabe prüft automatisch die Stornierung des Elternteils let (data, _) = try await URLSession.shared.data(from: url) return data } } // Simulation der Benutzern-Stornierung group.cancelAll() var results: [Data] = [] for try await data in group { results.append(data) } return results } }
Eine Medienverarbeitungsanwendung musste Miniaturansichten für 10.000 Bilder erstellen, während die Benutzer mid-flight abbrechen konnten. Das Engineering-Team verwendete zunächst einen DispatchGroup-Ansatz, um aktive URLSessionDataTask-Objekte in einer thread-sicheren NSHashTable zu verfolgen, um die Stornierung zu ermöglichen.
Die erste Lösung nutzte DispatchGroup mit einem DispatchSemaphore, um die Parallelität zu begrenzen. Während sie funktional war, erforderte dies komplexe Logik, um abgeschlossene Aufgaben aus der Stornierungsmenge zu entfernen. Rennbedingungen traten auf, bei denen Aufgaben zwischen dem Stornierungssignal und der Aufzählung der Menge abgeschlossen wurden, wodurch die App auf freigegebene Objekte verwies. Dieser Ansatz führte auch zu Speicherlecks, wenn der Ansichtscontroller verworfen wurde, da DispatchGroup-Benachrichtigungen den Delegaten stark behielten.
Der zweite Ansatz übernahm das FlatMap von Combine mit einem PassthroughSubject für die Stornierung. Dies bot eine bessere Zusammensetzung, führte jedoch zu einem signifikanten Speicherüberhead durch die Zuweisung der Publisher-Kette. Die Propagation der Stornierung erforderte das Speichern von AnyCancellable-Token in einer Sammlung, die eine manuelle Bereinigung erforderte. Die deklarative Abstraktion verbarg die tatsächliche Aufgabenhierarchie, was das Debuggen erschwerte, wenn Stornierungssignale durch die Operator-Kette nicht propagiert wurden.
Das Team migrierte zu Swifts TaskGroup. Dies beseitigte das manuelle Management von NSHashTable, da die Laufzeit jeder Miniaturansicht-Generierungsaufgabe automatisch mit dem Stornierungsbereich der Gruppe verknüpfte. Wenn der Benutzer auf Abbrechen tippte, rief der Ansichtscontroller group.cancelAll() auf, was atomar alle laufenden Aufgaben signalisierte, an ihrem nächsten await-Punkt zu stoppen. Diese Lösung garantierte, dass keine verwaisten Aufgaben nach der Deallokation der Ansicht weiterverarbeitet wurden, und die deterministische Scoping von withThrowingTaskGroup stellte eine automatische Bereinigung sicher, selbst wenn die Funktion einen Fehler auslöste.
Die Stornierungslatenz fiel von durchschnittlich 500 ms (Warten auf manuelle Mengenumfang) auf unter 10 ms (direkte Durchlauf durch die verkettete Liste). Die Speicherprofilierung zeigte null geleakte Task-Objekte nach der Stornierung, und der Code wurde um 40 Zeilen Synchronisations-Boilerplate reduziert.
Wie behandelt TaskGroup die Situation, in der eine untergeordnete Aufgabe die Stornierung ignoriert und unbegrenzt weiterläuft?
Bewerber glauben oft, dass TaskGroup Aufgaben zwangsweise beendet oder Ausnahmen einfügt. In Wirklichkeit ist die Stornierung in Swift kooperativ: Die Laufzeit setzt das isCancelled-Flag im Kontext der Aufgabe, aber die Aufgabe läuft weiter, bis sie einen Punkt der Aussetzung erreicht oder explizit Task.isCancelled überprüft. Die untergeordnete Aufgabe muss regelmäßig Task.checkCancellation() abfragen oder auf stornierungsbewusste APIs zurückgreifen. Wenn eine Aufgabe eine enge CPU-gebundene Schleife ohne Aussetzpunkte ausführt, blockiert sie den Abschluss der Gruppe unbegrenzt. Um dies zu verhindern, sollten lang laufende Berechnungen Task.yield() verwenden oder Arbeiten in Stücke aufteilen, die Stornierungsflags überprüfen.
Warum führt das Hinzufügen einer Aufgabe zu einer TaskGroup nach dem Aufrufen von cancelAll() dennoch zur sofortigen Stornierung dieser neuen Aufgabe?
Viele nehmen an, dass cancelAll() ein einmaliges Signal ist, das nur an bestehende Kinder gesendet wird. Die Implementierung von Swift markiert jedoch die TaskGroup selbst als storniert in ihrem Statusprotokoll. Wenn addTask anschließend aufgerufen wird, überprüft die Laufzeit atomar den Stornierungsstatus der Gruppe während der Aufgaben Erstellung; falls storniert, wird die neue untergeordnete Aufgabe mit ihrem isCancelled-Flag vorab gesetzt. Dies stellt sicher, dass spät hinzugefügte Aufgaben nicht aus dem Stornierungsbereich entkommen können, wodurch die strukturelle Garantie aufrechterhalten wird, dass ein stornierter Bereich keine neuen gültigen Ergebnisse erzeugen kann. Dies verhindert Rennbedingungen, bei denen Aufgaben, die während des Abbaus der Stornierung hinzugefügt werden, durchrutschen.
Was ist der grundlegende Unterschied zwischen der strukturierten Konkurrenz von TaskGroup und einer Aufgabe, die über Task.init erstellt wurde, in Bezug auf das Speichermanagement der erfassten Variablen?
Bewerber übersehen häufig, dass untergeordnete Aufgaben von TaskGroup die Schauspielerisolation und Priorität des übergeordneten Kontexts erben, aber entscheidender ist, dass sie die Lebensdauer der erfassten Variablen nur bis zum Verlassen des Gruppenbereichs verlängern. Im Gegensatz dazu persistieren unstrukturierte Task-Objekte, die mit Task { ... } erstellt werden, über die Lebensdauer des Erstellungsbereichs hinaus und können self potenziell unbegrenzt erfassen. Das bedeutet, dass in TaskGroup, wenn Sie self in addTask erfassen, Sie [weak self] nicht benötigen, weil die Aufgabe die withThrowingTaskGroup-Block nicht überleben kann. Entwickler wenden jedoch oft fälschlicherweise [weak self]-Muster aus unstrukturierten Aufgaben an, was den Code unnötig kompliziert und möglicherweise nil-Referenzfehler einführt, wenn sie sich auf das Vorhandensein von self für den Abschluss stützen.