Comprendre le modèle de concurrence de Swift 6 : tâches, priorités d'exécution et l'évolution au-delà de la planification préemptive

Swift 6 révolutionne fondamentalement la façon dont les développeurs abordent la programmation concurrente. Plutôt que de s’appuyer sur des mécanismes traditionnels de planification préemptive, le nouveau framework d’Apple introduit un modèle d’exécution coopératif associé à une gestion intelligente des tâches. Ce guide complet décompose ce qui rend ce changement de paradigme nécessaire, comment il fonctionne en temps réel, et pourquoi il est crucial pour construire des applications réactives et sûres.

Le problème de la concurrence : pourquoi Swift avait besoin d’une nouvelle approche

La programmation concurrente reste l’un des défis les plus épineux du développement logiciel. Lorsque plusieurs tâches s’exécutent simultanément, les applications gagnent en performance et en réactivité, mais les développeurs doivent faire face à un véritable champ de mines de problèmes potentiels : conditions de course, blocages mutuels, violations de la sécurité des threads qui gangrènent le code en production.

Swift Concurrency, lancé avec Swift 6, aborde ces problèmes de front avec une philosophie différente de la planification préemptive traditionnelle utilisée par les systèmes d’exploitation. Plutôt que de laisser le système d’exploitation interrompre arbitrairement les tâches à tout moment, le runtime de Swift impose des points de contrôle coopératifs où la suspension se produit naturellement.

Les principaux problèmes traités :

• Conditions de course : Plusieurs threads accédant simultanément à des données mutables partagées créent des résultats imprévisibles. Le nouveau modèle impose une propriété claire et des modèles d’accès sûrs.
• Complexité des callbacks : Les gestionnaires de complétion imbriqués rendent le code difficile à suivre. La syntaxe async/await simplifie considérablement cette charge cognitive.
• Surcharge des threads : La gestion des threads au niveau du système d’exploitation implique des changements de contexte coûteux et une allocation de ressources. L’approche de Swift abstrait complètement cela.
• Coordination des tâches : La concurrence structurée fournit des hiérarchies explicites, rendant l’annulation de tâches et la gestion des erreurs plus simples.

En combinant async/await, Actors et modèles de concurrence structurée, Swift 6 offre un modèle de concurrence plus sûr, plus intuitif, sans sacrifier la performance.

Modèles multitâches : planification préemptive vs exécution coopérative

Pour apprécier la conception de Swift, il est essentiel de comprendre comment les modèles d’exécution divergent. Les systèmes d’exploitation et les environnements d’exécution traditionnels basés sur des threads utilisent la planification préemptive — une stratégie qui contraste fortement avec l’approche coopérative de Swift.

Le modèle de planification préemptive

Les systèmes d’exploitation traditionnels utilisent la planification préemptive, où le noyau peut interrompre de force n’importe quel thread à pratiquement n’importe quel moment de l’exécution. Ce changement de contexte se produit sans que le thread en ait connaissance ou coopération. Le système sauvegarde l’état du thread (registres CPU, pointeurs d’instruction, contenu de la pile), puis passe à un autre thread, et plus tard restaure l’état du thread original pour reprendre le travail.

Avantages de la planification préemptive :

• Garantit l’équité — aucun thread ne peut étouffer les autres
• Permet un parallélisme réel sur plusieurs cœurs CPU
• Protège le système contre des threads malveillants monopolistes

Le coût : La planification préemptive engendre une surcharge importante. Les changements de contexte vidangent les caches CPU, invalident les buffers de traduction, et transitent entre modes utilisateur et noyau. Chaque changement consomme des cycles CPU mesurables. Plus critique encore, les points d’interruption imprévisibles obligent les développeurs à encapsuler l’état mutable partagé dans des primitives de synchronisation — mutex, sémaphores, opérations atomiques. Omettre une seule de ces synchronisations peut entraîner des conditions de course, des plantages ou des bugs intermittents difficiles à reproduire et à tester.

Ce fardeau repose entièrement sur le développeur. Construire un code thread-safe dans un environnement préemptif nécessite une vigilance constante et une expertise approfondie en concurrence, rendant ce code sujet aux erreurs et difficile à raisonner.

Le modèle d’exécution coopératif de Swift

Swift 6 inverse cette approche. Plutôt que la planification préemptive imposée par le système, les tâches cèdent explicitement le contrôle à des points bien définis — généralement lors d’expressions await ou via Task.yield(). Le runtime ne force jamais l’interruption d’une tâche.

Cette stratégie coopérative offre des avantages remarquables :

• Prédictibilité : Les points de suspension sont explicites et visibles dans le code. Les développeurs savent exactement où se produisent les changements de contexte.
• Surcharge moindre : Aucun changement de contexte coûteux. Le runtime invoque simplement la continuation suivante en file d’attente — une opération légère.
• Concurrence plus sûre : Avec des points de suspension contrôlés, les conditions de course deviennent beaucoup moins probables. Le compilateur impose la conformité à Sendable pour empêcher le partage de données non sécurisé entre les frontières des tâches.

Cependant, la coopération implique une responsabilité. Si une tâche s’exécute sans se suspendre, elle monopolise son thread d’exécution, privant les autres de ressources. Les opérations longues doivent inclure explicitement des appels à Task.yield() pour rester “de bons citoyens” dans le système coopératif.

Sous le capot : continuations, pas threads

Le runtime de Swift traite l’exécution différemment des threads traditionnels. Lorsqu’une fonction async se suspend à un point await :

1. Le compilateur transforme la fonction en une machine à états, capturant son contexte d’exécution (variables locales, pointeur d’instruction) dans une continuation allouée sur le tas.
2. Plutôt que de bloquer un thread, cette continuation est mise en file d’attente pour une exécution ultérieure.
3. Le thread d’exécution — au lieu d’attendre — récupère la prochaine continuation prête dans sa file.
4. Lorsque l’opération en attente se termine, la continuation suspendue est réenfilée et reprend éventuellement.

Ce modèle basé sur les continuations élimine le besoin de piles de threads et de changements de contexte OS. L’échange : une utilisation légèrement plus importante de mémoire heap pour stocker l’état async suspendu, mais une surcharge de changement de tâche bien inférieure. Pour les charges de travail liées à l’I/O — où les tâches passent la majorité de leur temps à attendre plutôt qu’à calculer — cet échange favorise fortement le modèle coopératif.

La tâche : unité de travail concurrente de Swift

Dans la concurrence Swift, une Task encapsule une unité de travail asynchrone. Contrairement à simplement appeler une fonction async, une Task est un objet géré qui s’exécute dans un pool de threads coopératif aux côtés d’autres tâches.

Création et gestion des tâches

L’initialiseur standard lance immédiatement une tâche :