En Objective-C, on distingue les propriétés atomiques et non atomiques :
@property (nonatomic, strong) NSObject *nonatomicObject;
@property (atomic, strong) NSObject *atomicObject;
D'après ce que j'ai compris, vous pouvez lire et écrire des propriétés définies comme atomiques à partir de plusieurs threads en toute sécurité, tandis que l'écriture et l'accès à des propriétés non atomiques ou à des ivars à partir de plusieurs threads en même temps peuvent entraîner un comportement non défini, y compris des erreurs de mauvais accès.
Donc si vous avez une variable comme ceci dans Swift :
var object: NSObject
Puis-je lire et écrire dans cette variable en parallèle en toute sécurité ? (Sans tenir compte de la signification réelle de cette opération).
0 votes
Je pense qu'à l'avenir, nous pourrons peut-être utiliser
@atomic
o@nonatomic
. ou simplement atomique par défaut. (Swift est tellement incomplet qu'on ne peut pas dire grand chose pour l'instant)1 votes
IMO, ils rendront tout non-atomique par défaut, et fourniront probablement une fonction spéciale pour rendre les choses atomiques.
0 votes
En passant,
atomic
n'est généralement pas considéré comme suffisant pour une interaction sûre avec une propriété, sauf pour les types de données simples. Pour les objets, on synchronise généralement l'accès entre les threads en utilisant des verrous (par ex,NSLock
o@synchronized
) ou des files d'attente GCD (par exemple, une file d'attente série ou une file d'attente concurrente avec un modèle "lecteur-écrivain").0 votes
@Rob, c'est vrai, bien qu'en raison du comptage des références en Objective-C (et peut-être en Swift), la lecture et l'écriture simultanées d'une variable sans accès atomique peuvent entraîner une corruption de la mémoire. Si toutes les variables avaient un accès atomique, la pire chose qui pourrait arriver serait une condition de course "logique", c'est-à-dire un comportement inattendu.
0 votes
Ne vous méprenez pas : j'espère qu'Apple répondra/résolvera la question du comportement atomique. C'est juste que (a)
atomic
ne garantit pas la thread-safety pour les objets ; et (b) si l'on utilise correctement l'une des techniques de synchronisation susmentionnées pour garantir la thread-safety (entre autres choses, en empêchant les lectures/écritures simultanées), le problème atomique est sans objet. Mais nous en avons toujours besoin pour les types de données simples, oùatomic
a une réelle valeur. Bonne question !0 votes
@Rod de votre commentaire, 1.
atomic
n'a de sens que pour les primitives. 2.atomic
ne garantit pas la sécurité thread pour les objets, par exemple.NSObject
et ses descendantes. C'est exact ?0 votes
@Rob Vous avez tort, atomique est suffisante pour l'interaction en toute sécurité avec un propriété . Il se peut que cela ne soit pas suffisant pour une interaction parfaitement sûre avec un objet entier, car parfois deux propriétés ou plus doivent être modifiées de manière atomique pour représenter un état cohérent ; par exemple, un élément doit être ajouté à une structure de données et un compteur doit être augmenté - soit les deux se produisent, soit aucun ne se produit, mais si un seul des deux se produit, l'objet est dans un état "cassé". Mais si une telle dépendance n'existe pas, un objet avec toutes les propriétés atomiques est lui-même totalement thread-safe.
0 votes
Vous mentionnez un problème (la synchronisation de cette propriété avec d'autres propriétés du contexte plus large qui est généralement un problème critique). Le deuxième problème est que si la propriété, elle-même, fait référence à un objet, le fait de rendre la référence atomique ne rend pas la propriété référencée thread-safe. Cela rend seulement la manipulation de ce pointeur thread-safe (c'est-à-dire que le pointeur ne peut pas être corrompu), mais si l'objet sous-jacent qu'il référence n'est pas thread-safe, cela ne sert à rien.
atomic
a une utilité limitée pour les types de données fondamentaux, mais au-delà, elle est rarement suffisante.