Avant Swift 4, le langage permettait des accès mémoire chevauchants, s'appuyant sur la discipline du programmeur pour éviter les comportements indéfinis. Apple a introduit la Loi de l'Exclusivité comme une garantie fondamentale de sécurité mémoire, imposant qu'une variable ne puisse être accédée que par plusieurs lecteurs ou un seul écrivain, mais jamais simultanément par les deux.
Le problème principal survient lorsque deux références mutables – ou une référence mutable et une référence immutable – accèdent à la même localisation mémoire simultanément. Ce scénario se manifeste généralement avec des paramètres inout, des méthodes de mutation, ou des captures de fermeture chevauchantes, entraînant des courses de données, des instantanés incohérents ou une corruption de tas.
Swift met en œuvre une stratégie d'application hybride. Le compilateur effectue une analyse statique de définitions et d'utilisations pour rejeter les violations évidentes au moment de la compilation, comme passer la même variable comme deux arguments inout à une fonction. Pour les scénarios complexes impliquant des fermetures échappantes, des opérations de longue durée, ou un aliasing dépendant du runtime, le compilateur injecte une instrumentation dynamique. Ce suivi en temps d'exécution maintient un ensemble d'accès par thread ; lorsqu'un accès mutable chevauchant est détecté, le programme s'interrompt immédiatement plutôt que de présenter un comportement indéfini.
struct SignalProcessor { var waveform: [Float] mutating func amplify(by factor: Float, using buffer: (inout [Float]) -> Void) { buffer(&waveform) } } var processor = SignalProcessor(waveform: [0.1, 0.2, 0.3]) // Interruption à l'exécution : accès chevauchant à 'processor.waveform' processor.amplify(by: 2.0) { wave in processor.waveform = [1.0] // Tentative d'écriture pendant que 'wave' détient une référence inout wave[0] = 0.5 }
Une application de synthèse audio en temps réel pour iOS rendait des tampons audio sur une DispatchQueue de haute priorité tandis que le thread de l'interface utilisateur visualisait les données de forme d'onde. Des plantages intermittents se produisaient lors d'ajustements rapides de paramètres, les journaux de plantage indiquant une corruption du tas au sein des opérations UnsafeMutablePointer.
L'équipe de développement a envisagé trois solutions architecturales distinctes.
Implémentation utilisant la synchronisation os_unfair_lock. Ils ont protégé la structure AudioBuffer partagée avec un spinlock léger. Bien que cela ait permis d'éviter les courses de données, le contenuion de verrou entre le callback audio (qui ne doit jamais se bloquer) et le thread UI a provoqué des coupures audio. De plus, une inversion de priorité s'est produite lorsque l'interface utilisateur maintenait le verrou pendant que le thread en temps réel attendait, violant les exigences strictes de temps de Core Audio.
Implémentation utilisant la copie de valeurs immuables. Ils ont refactorisé le AudioBuffer en un struct et ont passé des copies au thread de l'interface utilisateur à chaque image. Cela a éliminé les besoins de synchronisation, mais a introduit une latence inacceptable. Copier des tampons de 1024 échantillons à 60Hz allouait des mégaoctets de mémoire temporaire par seconde, déclenchant le trafic ARC de Swift et la pression d'allocateur de Core Foundation qui causaient des problèmes audio audibles.
Implémentation tirant parti de l'exclusivité de Swift avec un champ d'application strict. Ils ont éliminé l'état mutable partagé en s'assurant que le callback audio détenait un accès exclusif au tampon uniquement dans un champ d'application bien défini, en utilisant des paramètres inout pour les étapes de traitement. L'interface utilisateur recevais des instantanés en lecture seule via des accesseurs nonmutants. Cette solution a été choisie car elle utilisait les vérifications d'exclusivité à la compilation de Swift pour prouver la sécurité, éliminant entièrement les surcharges de synchronisation à l'exécution tout en empêchant toute possibilité de mutation chevauchante.
Le refactoring a éliminé tous les plantages dus à la corruption du tas. L'utilisation du CPU a chuté de 40 % en raison de la suppression des primitives de verrouillage et du changement d'allocation de mémoire, et le pipeline audio a atteint un fonctionnement sans problème sous forte charge.
Pourquoi l'application de l'exclusivité permet-elle un accès en lecture simultanée mais s'arrête sur un accès en lecture-écriture chevauchant, et comment Swift les distingue-t-il au niveau du code machine ?
Les candidats confondent souvent l'exclusivité avec la sécurité générale des threads. Swift permet plusieurs accès simultanés en lecture seule car ils ne peuvent pas modifier l'état, mais toute écriture nécessite l'exclusivité. Au niveau du code machine, le compilateur omet le suivi en temps d'exécution pour l'accès en lecture seule (à moins d'être compilé avec le vérificateur de threads), tandis que les écritures déclenchent des appels à l'exécution swift_beginAccess qui enregistrent la localisation mémoire dans un ensemble d'accès local au thread. Le runtime utilise un système de drapeau (read vs modify) pour déterminer les conflits, permettant des lectures simultanées mais s'arrêtant lorsqu'un drapeau modify rencontre un accès existant de toute sorte.
Comment Swift gère-t-il les violations d'exclusivité qui s'étendent à travers des points de suspension dans le code async/await ?
De nombreux candidats supposent que async/await résout automatiquement les préoccupations d'exclusivité. Cependant, Swift traite await comme une potentielle frontière d'accès. Si une tâche détient une référence inout à une variable et rencontre un await, le compilateur doit prouver que l'accès se termine avant la suspension ou l'étendre à travers la suspension. Le runtime suit ces accès par tâche. Si une autre tâche tente d'accéder à la même mémoire tandis que la première est suspendue en détenant des droits exclusifs, le runtime s'arrête. Les développeurs doivent éviter de maintenir des références inout à travers les frontières await ou encapsuler l'état au sein des Actors pour garantir une isolation appropriée à travers la suspension.
Sous quel drapeau d'optimisation spécifique du compilateur la vérification d'exclusivité à l'exécution est-elle désactivée, et quels modes d'échec catastrophiques en résultent ?
Les candidats croient fréquemment que l'exclusivité est immuable. Swift fournit le mode de compilation -Ounchecked, qui désactive toutes les vérifications d'exclusivité à l'exécution pour le code critique en termes de performance. Dans cette configuration, les violations d'exclusivité latentes – telles que les modifications inout chevauchantes par des fermetures concurrentes – produisent une corruption silencieuse du tas plutôt que des interruptions déterministes. Cela peut se manifester par la corruption des données de String où les champs de longueur ne correspondent plus aux contenus du tampon, une métadonnée Array corrompue conduisant à des accès mémoire hors limites, ou une exécution de code arbitraire si des pointeurs corrompus sont ensuite déréférencés. Ce drapeau ne devrait être utilisé que lorsque la vérification formelle ou l'analyse statique exhaustive a prouvé l'absence d'accès chevauchants.