Swift's concurrentiemodel onderging een paradigmawisseling met Swift 5.5, waarbij gestructureerde concurrentie werd geïntroduceerd ter vervanging van verouderde Grand Central Dispatch-patronen die vaak leidden tot wees-taken en hulpbronnenlekken. Voordat dit gebeurde, beheerde de ontwikkelaars handmatig DispatchGroup-instanties om gelijktijdig werk bij te houden, wat expliciete synchronisatie vereiste om racecondities tijdens annuleringen te voorkomen. De TaskGroup-abstractie is ontworpen om de ouder-kindrelatietree op een native manier in te kapselen, zodat de runtime lifecycle-metadata behoudt in plaats van de ontwikkelaar.
Het kernprobleem ligt in het handhaven van een deterministische hiërarchie waarin ouderlijke taken op betrouwbare wijze annuleringen kunnen signaliseren aan alle afstammelingen zonder wereldwijde registers of handmatige zwakke referentielijsten te doorlopen. Traditionele benaderingen die OperationQueue gebruiken, vereisen expliciete registratie en deregistratie van voltooiingshandlers, wat fragiele statusbeheer creëert die faalt als een voltooiingshandler wordt overgeslagen vanwege een vroegtijdige exit. Bovendien vereist de propagatie van annuleringen complexe atomische vlagpolling, wat vaak leidt tot vertraagde responsiviteit of overmatige CPU-overhead.
Swift pakt dit aan door een takenrecord binnen de context van elke taak in te bedden dat naar de ouder wijst, waardoor een indringende gekoppelde lijst ontstaat die is verankerd aan de TaskGroup. Wanneer addTask wordt aangeroepen, plaatst de runtime een kindtakenrecord in deze lijst, en registreert het atomisch bij de annuleringhandler van de ouder. Het annuleringmechanisme maakt gebruik van een toestandsmachine: wanneer cancelAll() wordt aangeroepen, doorloopt de runtime deze lijst, stelt het isCancelled-vlag in voor de metadata van elke kindtaak en wekt het opgeschorte executors. Dit zorgt voor O(n) propagatie, waarbij n de diepte van de boom is, en vermijdt wereldwijde vergrendelingen.
import Foundation func downloadImages(urls: [URL]) async throws -> [Data] { try await withThrowingTaskGroup(of: Data.self) { group in for url in urls { group.addTask { // Kindtaak controleert automatisch de annulering van de ouder let (data, _) = try await URLSession.shared.data(from: url) return data } } // Simuleren van gebruikersannulering group.cancelAll() var results: [Data] = [] for try await data in group { results.append(data) } return results } }
Een media-verwerkingsapplicatie moest miniaturen genereren voor 10.000 afbeeldingen terwijl gebruikers halverwege konden annuleren. Het engineeringteam gebruikte aanvankelijk een DispatchGroup-benadering en volgde actieve URLSessionDataTask-objecten in een thread-veilige NSHashTable om annulering mogelijk te maken.
De eerste oplossing gebruikte DispatchGroup met een DispatchSemaphore om de gelijktijdigheid te beperken. Hoewel functioneel, vereiste dit complexe logica om voltooide taken uit de annuleringstelset te verwijderen. Racecondities deden zich voor wanneer taken voltooiden tussen het annuleringssignaal en de enumeratie van de set, waardoor de app gedeallocateerde objecten referentieerde. Deze aanpak lekte ook geheugen toen de view-controller werd afgesloten, omdat DispatchGroup-meldingen de delegate sterk vasthielden.
De tweede aanpak nam Combine's FlatMap aan met een PassthroughSubject voor annulering. Dit bood betere samenstelbaarheid, maar introduceerde aanzienlijke geheugenkosten door het toewijzen van de publicatieketen. De propagatie van annuleringen vereiste het opslaan van AnyCancellable-tokens in een collectie die handmatige opruiming vereiste. De declaratieve abstractie verstopte de werkelijke taakhiërarchie, waardoor het debuggen moeilijk werd wanneer annuleringseinen faalden om door de operator keten te propagateren.
Het team migreerde naar Swift's TaskGroup. Dit maakte handmatig NSHashTable-beheer overbodig omdat de runtime automatisch elke taak voor het genereren van miniaturen koppelde aan het annuleringdomein van de groep. Wanneer de gebruiker op annuleren tikte, riep de view-controller group.cancelAll() aan, wat atomisch alle actieve taken signaliseerde om te stoppen bij hun volgende await-onderbreking. Deze oplossing garandeerde dat er geen wees-taken doorgingen met verwerken na de deallocatie van de weergave, en de deterministische scoping van withThrowingTaskGroup zorgde voor automatische opruiming, zelfs als de functie een fout gooide.
De annuleringlatentie daalde van gemiddeld 500 ms (wachten op handmatige setenumeratie) naar minder dan 10 ms (directe doorloop van de gekoppelde lijst). Geheugenprofilering toonde aan dat er nul gelekte Task-objecten waren na annulering, en de codebase werd met 40 regels synchronisatie-boilerplate verminderd.
Hoe gaat TaskGroup om met het scenario waarin een kindtaak de annulering negeert en oneindig blijft uitvoeren?
Kandidaten geloven vaak dat TaskGroup taken met geweld beëindigt of uitzonderingen injecteert. In werkelijkheid is de annulering in Swift coöperatief: de runtime stelt de isCancelled-vlag in de context van de taak in, maar de taak gaat door totdat deze een onderbrekingspunt of een expliciete controle op Task.isCancelled raakt. De kindtaak moet periodiek Task.checkCancellation() pellen of vertrouwen op annulering-bewuste API's. Als een taak een strakke CPU-bound lus uitvoert zonder onderbrekingpunten, blokkeert dit de voltooiing van de groep oneindig. Om dit te voorkomen, moeten langlopende berekeningen Task.yield() gebruiken of werk in stukken splitsen die de annuleringsvlaggen controleren.
Waarom leidt het toevoegen van een taak aan een TaskGroup na het aanroepen van cancelAll() nog steeds tot onmiddellijke annulering van die nieuwe taak?
Veel mensen vermoeden dat cancelAll() een eenmalig signaal is dat alleen aan bestaande kinderen wordt verzonden. Echter, de implementatie van Swift markeert de TaskGroup zelf als geannuleerd in zijn statusrecord. Wanneer addTask later wordt aangeroepen, controleert de runtime atomisch de annuleringstoestand van de groep tijdens de taakcreatie; als deze geannuleerd is, wordt de nieuwe kindtaak gemaakt met zijn isCancelled-vlag vooraf ingesteld. Dit zorgt ervoor dat laat toegevoegde taken niet kunnen ontsnappen aan het annuleringdomein, waardoor de structurele garantie wordt gehandhaafd dat een geannuleerde scope geen nieuwe geldige resultaten kan produceren. Dit voorkomt racecondities waarbij taken die tijdens de afbouw van annuleringen zijn toegevoegd, ontsnappen.
Wat is het fundamentele verschil tussen de gestructureerde concurrentie van TaskGroup en een taak gemaakt via Task.init met betrekking tot het geheugbeheer van vastgelegde variabelen?
Kandidaten overzien vaak dat TaskGroup kindtaken de actorisolatie en prioriteit van de oudercontext erven, maar nog belangrijker is dat ze de levensduur van vastgelegde variabelen alleen verlengen tot de groep scope verlaat. In tegenstelling hiermee blijven ongestructureerde Task-objecten gemaakt met Task { ... } bestaan na de levensduur van de scheppende scope, waardoor ze self mogelijk oneindig vastleggen. Dit betekent dat in TaskGroup, als je self in addTask vastlegt, je niet [weak self] nodig hebt omdat de taak niet kan overleven na de withThrowingTaskGroup-blok. Ontwikkelaars passen echter vaak ten onrechte [weak self]-patronen toe van ongestructureerde taken, wat de code onnodig ingewikkeld maakt en mogelijk nul-referentiefouten introduceert als ze afhankelijk zijn van self die aanwezig is voor voltooiing.