Quelle est la différence entre les attributs atomiques et non atomiques?

Question

Que signifient atomic et nonatomic dans les déclarations de propriété?

@property(nonatomic, retain) UITextField *userName;
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName;

Quelle est la différence opérationnelle entre ces trois?

Answer 1

Les deux derniers sont identiques; "atomic" est le comportement par défaut (notez que ce n'est pas réellement un mot clé; il est spécifié uniquement par l'absence de nonatomic - atomic a été ajouté en tant que mot clé dans les versions récentes de llvm/clang).

En supposant que vous synthétisiez les implémentations de la méthode, atomique par rapport à non atomique modifie le code généré. Si vous écrivez votre propre setter/getters, atomic/nonatomic/rétention/assign/copie sont simplement consultatifs. (Remarque: @synthesize est désormais le comportement par défaut des versions récentes de LLVM. Il n'est pas non plus nécessaire de déclarer des variables d'instance; elles seront également synthétisées automatiquement et un code _ sera ajouté à leur nom pour éviter tout accès direct accidentel).

Avec "atomic", le setter/getter synthétisé s'assurera qu'une valeur entière est toujours renvoyée par le getter ou définie par le setter, quelle que soit l'activité de ce dernier sur un autre thread. En d’autres termes, si le thread A se trouve au milieu du getter pendant que le thread B appelle le passeur, une valeur viable réelle - un objet autoreleased, très probablement - sera renvoyée à l’appelant dans A.

Dans nonatomic, aucune garantie de ce type n'est faite. Ainsi, nonatomic est considérablement plus rapide que "atomique".

Ce que "atomique" fait pas ne fait, c’est aucune garantie sur la sécurité du fil. Si le thread A appelle le getter simultanément avec les threads B et C appelant le poseur avec des valeurs différentes, le thread A peut obtenir n'importe laquelle des trois valeurs renvoyées - celle précédant l'appel des setters ou l'une des valeurs transmises aux setters. De même, l'objet peut se retrouver avec la valeur de B ou C, pas moyen de le dire.

L'intégration des données, l'un des principaux défis de la programmation multithread, passe par d'autres moyens.

Ajoutant à cela:

atomicity d'une propriété unique ne peut pas non plus garantir la sécurité des threads lorsque plusieurs propriétés dépendantes sont en jeu.

Considérer:

 @property(atomic, copy) NSString *firstName;
 @property(atomic, copy) NSString *lastName;
 @property(readonly, atomic, copy) NSString *fullName;

Dans ce cas, le thread A pourrait renommer l'objet en appelant setFirstName:, puis en appelant setLastName:. Entre-temps, le thread B peut appeler fullName entre les deux appels du thread A et recevra le nouveau prénom associé à l'ancien nom de famille.

Pour résoudre ce problème, vous avez besoin d'un modèle transactionnel. C'est à dire. un autre type de synchronisation et/ou d’exclusion permettant d’exclure l’accès à fullName pendant la mise à jour des propriétés dépendantes.

Answer 2

Ceci est expliqué dans la documentation d'Apple, mais vous trouverez ci-dessous quelques exemples de ce qui se passe réellement. Notez qu'il n'y a pas de mot clé "atomique". Si vous ne spécifiez pas "nonatomique", la propriété est atomique, mais spécifier explicitement "atomique" entraînera une erreur.

//@property(nonatomic, retain) UITextField *userName;
//Generates roughly

- (UITextField *) userName {
    return userName;
}

- (void) setUserName:(UITextField *)userName_ {
    [userName_ retain];
    [userName release];
    userName = userName_;
}

Maintenant, la variante atomique est un peu plus compliquée:

//@property(retain) UITextField *userName;
//Generates roughly

- (UITextField *) userName {
    UITextField *retval = nil;
    @synchronized(self) {
        retval = [[userName retain] autorelease];
    }
    return retval;
}

- (void) setUserName:(UITextField *)userName_ {
    @synchronized(self) {
      [userName_ retain];
      [userName release];
      userName = userName_;
    }
}

Fondamentalement, la version atomique doit prendre un verrou afin de garantir la sécurité des threads, et bloque le décompte ref sur l'objet (et le décompte autorelease pour l'équilibrer) afin que l'objet soit garanti pour l'appelant, sinon est une condition de concurrence possible si un autre thread définit la valeur, ce qui ramène le nombre de références à 0.

Il existe en fait un grand nombre de variantes différentes de la façon dont ces choses fonctionnent, selon que les propriétés sont des valeurs scalaires ou des objets, et comment En général, les synthétiseurs de propriétés savent juste comment faire la "bonne chose" pour toutes les combinaisons.

Answer 3

Atomique

• est le comportement par défaut
• s'assurera que la CPU termine le processus actuel avant qu'un autre processus n'accède à la variable
• n'est pas rapide, car il garantit que le processus est entièrement terminé

Non-atomique

• n'est pas le comportement par défaut
• plus rapide (pour le code synthétisé, c'est-à-dire pour les variables créées avec @property et @synthesize)
• pas thread-safe
• peut entraîner un comportement inattendu, lorsque deux processus différents accèdent simultanément à la même variable

Answer 4

La meilleure façon de comprendre la différence consiste à utiliser l'exemple suivant. 

Supposons qu'il existe une propriété de chaîne atomique appelée "nom" et que si vous appelez [self setName:@"A"] à partir du thread A, appelez [self setName:@"B"] à partir du thread B et appelez [self name] à partir du thread C, toutes les opérations sur les différents threads seront effectuées en série, ce qui signifie que si un thread est en exécutant un setter ou un getter, les autres threads attendront.

Cela sécurise la propriété "name" en lecture/écriture, mais si un autre thread, D, appelle [name release] simultanément, cette opération risque de provoquer un blocage, car il n'y a pas d'appel setter/getter impliqué ici. Ce qui signifie qu'un objet est sécurisé en lecture/écriture (ATOMIC), mais n'est pas thread-safe car d'autres threads peuvent envoyer simultanément tout type de message à l'objet. Le développeur doit garantir la sécurité des threads pour de tels objets.

Si la propriété "name" n'était pas atomique, tous les threads de l'exemple ci-dessus - A, B, C et D s'exécuteront simultanément, produisant un résultat imprévisible. En cas d'atome, l'un des A, B ou C s'exécutera en premier, mais D peut toujours s'exécuter en parallèle.

Answer 5

La syntaxe et la sémantique sont déjà bien définies par d’autres excellentes réponses à cette question. Parce que l'exécution et la performance ne sont pas bien détaillées, je vais ajouter ma réponse.

Quelle est la différence fonctionnelle entre ces 3?

J'avais toujours considéré l'atome comme un défaut assez curieux. Au niveau de l'abstraction, nous travaillons à l'utilisation des propriétés atomiques d'une classe en tant que véhicule pour atteindre 100% de sécurité du thread, c'est un cas d'école. Pour les programmes multithread vraiment corrects, l'intervention du programmeur est presque certainement une nécessité. En attendant, les caractéristiques de performance et d'exécution n'ont pas encore été détaillées en détail. Ayant écrit des programmes fortement multithreads au fil des ans, j’avais déclaré mes propriétés comme nonatomic pendant tout ce temps, parce que atomique n’était sensé à aucune fin. Au cours de la discussion sur les détails des propriétés atomiques et non atomiques cette question , j'ai fait du profilage qui a donné des résultats curieux.

Exécution

D'accord. La première chose que je voudrais éclaircir est que l'implémentation de verrouillage est définie et abstraite. Louis utilise @synchronized(self) dans son exemple. J'ai vu cela comme une source commune de confusion. La mise en œuvre ne fait pas réellement utiliser @synchronized(self); il utilise le niveau d'objet . Le verrouille . L'illustration de Louis est bonne pour une illustration de haut niveau utilisant des constructions que nous connaissons tous, mais il est important de savoir qu'elle n'utilise pas @synchronized(self).

Une autre différence est que les propriétés atomiques retiennent/libèrent le cycle de vos objets dans le getter.

Performance

Voici la partie intéressante: Les performances utilisant des accès aux propriétés atomiques dans des cas non contestés (par exemple, à un seul thread) peuvent être très rapides dans certains cas. Dans des cas moins qu'idéaux, l'utilisation des accès atomiques peut coûter plus de 20 fois le temps système de nonatomic. Alors que le cas contesté utilisant 7 threads était 44 fois plus lent pour la structure à trois octets (2,2 GHz Core i7 Quad-Core , x86_64). La structure de trois octets est un exemple de propriété très lente.

Note latérale intéressante: les accesseurs définis par l'utilisateur de la structure à trois octets étaient 52 fois plus rapides que les accesseurs atomiques synthétisés; ou 84% de la vitesse des accesseurs non atomiques synthétisés.

Les objets dans les cas contestés peuvent également dépasser 50 fois.

En raison du nombre d'optimisations et de variations dans les implémentations, il est assez difficile de mesurer les impacts réels dans ces contextes. Vous entendrez peut-être souvent quelque chose du type "Faites-lui confiance, à moins que vous ne profiliez et découvriez que c'est un problème". En raison du niveau d'abstraction, il est en fait assez difficile de mesurer l'impact réel. Glaner les coûts réels des profils peut prendre beaucoup de temps et, en raison des abstractions, être assez imprécis. De plus, ARC vs MRC peut faire une grande différence.

Revenons donc en arrière et non pas sur la mise en œuvre des accès aux propriétés. Nous allons inclure les suspects habituels tels que objc_msgSend et examiner certains résultats de haut niveau dans le monde réel. pour de nombreux appels à un NSString getter dans des cas non contestés (valeurs en secondes):

• MRC | non atomique | getters implémentés manuellement: 2
• MRC | non atomique | getter synthétisé: 7
• MRC | atomique | getter synthétisé: 47
• ARC | non atomique | getter synthétisé: 38 (note: ARC ajoute le nombre de réf cyclistes ici)
• ARC | atomique | getter synthétisé: 47

Comme vous l'avez probablement deviné, l'activité/le cycle de comptage de références est un contributeur significatif avec les applications atomiques et sous ARC. Vous verriez également de plus grandes différences dans les cas contestés.

Bien que je porte une attention particulière aux performances, je dis toujours Sémantique d’abord! . Pendant ce temps, la performance n’est pas une priorité pour de nombreux projets. Cependant, connaître les détails d'exécution et les coûts des technologies que vous utilisez ne fait certainement pas de mal. Vous devez utiliser la technologie adaptée à vos besoins, objectifs et capacités. J'espère que cela vous évitera quelques heures de comparaison et vous aidera à prendre une décision plus éclairée lors de la conception de vos programmes.

Answer 6

Atomic = sécurité du fil

Non atomique = Pas de sécurité du fil

Fil de sécurité:

Les variables d'instance sont thread-safe si elles se comportent correctement lorsqu'elles sont accédées à partir de plusieurs threads, indépendamment de la planification ou de l'entrelacement de l'exécution de ces threads par l'environnement d'exécution et sans synchronisation ou autre coordination supplémentaire du code appelant.

Dans notre contexte:

Si un thread change la valeur de l'instance, la valeur modifiée est disponible pour tous les threads et un seul thread peut changer la valeur à la fois.

Où utiliser atomic:

si la variable d'instance est accessible dans un environnement multithread.

Implication de atomic:

Pas aussi vite que nonatomic car nonatomic ne nécessite aucun travail de surveillance sur ce point à partir de l'exécution.

Où utiliser nonatomic:

Si la variable d'instance ne doit pas être modifiée par plusieurs threads, vous pouvez l'utiliser. Cela améliore les performances.

Answer 7

J'ai trouvé une explication assez bien faite des propriétés atomiques et non atomiques ici . Voici un texte pertinent du même:

«atomique» signifie qu'il ne peut pas être décomposé. En termes de programmation/système d'exploitation, un appel de fonction atomique est un appel qui ne peut pas être interrompu - la fonction entière doit être exécutée et ne doit pas être extraite de la CPU par la commutation de contexte habituelle du système d'exploitation jusqu'à ce qu'elle soit terminée. Juste au cas où vous ne le sauriez pas: comme le processeur ne peut faire qu’une chose à la fois, le système d’exploitation fait pivoter l’accès du processeur à tous les processus en cours en petites tranches de temps pour donner le illusion du multitâche . Le planificateur de la CPU peut (et fait) interrompre un processus à n'importe quel moment de son exécution, même lors d'un appel de fonction. Ainsi, pour des actions telles que la mise à jour de variables de compteur partagées pour lesquelles deux processus peuvent essayer de mettre à jour la variable en même temps, ils doivent être exécutés "de manière atomique", c.-à-d. CPU.

Je suppose donc que, dans ce cas, atomique signifie que les méthodes de lecture d'attribut ne peuvent pas être interrompues, ce qui signifie que la ou les variables lues par la méthode ne peuvent pas changer leur valeur à mi-parcours car un autre thread/appel/fonction obtient échangé sur le processeur.

Etant donné que les variables atomic ne peuvent pas être interrompues, la valeur qu'elles contiennent à tout moment est (thread-lock) garantie d'être uncorrupted, bien que le fait de s'assurer que ce verrouillage de thread rend leur accès plus lent. non-atomic variables, en revanche, ne fournissent aucune garantie de ce type, mais offrent le luxe d’un accès plus rapide. Pour résumer, utilisez non-atomic lorsque vous savez que vos variables ne seront pas accessibles simultanément par plusieurs threads, ce qui accélérera les choses.

Answer 8

Après avoir lu tant d'articles, Stack Overflow et créé des applications de démonstration pour vérifier les attributs de propriétés variables, j'ai décidé de rassembler toutes les informations sur les attributs:

1. atomic/ Default
2. nonatomic
3. strong = retain // défaut
4. weak = unsafe_unretained
5. retain
6. assign // Default
7. unsafe_unretained
8. copy
9. readonly
10. readwrite // Default

Dans l'article _/Attributs de propriété de variable ou modificateurs sous iOS, vous pouvez trouver tous les attributs mentionnés ci-dessus, ce qui vous aidera certainement.

1. atomic

   • atomic signifie qu'un seul thread a accès à la variable (type statique).
   • atomic est thread-safe.
   • Mais la performance est lente
   • atomic est le comportement par défaut
   • Les accesseurs atomiques dans un environnement non récupéré (c'est-à-dire lors de l'utilisation de retenue/release/autorelease) utiliseront un verrou pour s'assurer qu'un autre thread n'interfère pas avec le réglage/obtention correct de la valeur.
   • Ce n'est pas réellement un mot clé. 
     
     

   Exemple:

       @property (retain) NSString *name;
   
       @synthesize name;
   

2. nonatomic

   • nonatomic signifie que plusieurs threads ont accès à la variable (type dynamique).
   • nonatomic est thread-unsafe.
   • Mais c'est rapide en performance
   • nonatomic n'est PAS un comportement par défaut. Nous devons ajouter le mot clé nonatomic dans l'attribut de propriété.
   • Cela peut entraîner un comportement inattendu, lorsque deux processus (threads) différents accèdent à la même variable en même temps. 
     
     

   Exemple:

       @property (nonatomic, retain) NSString *name;
   
       @synthesize name;
   

Answer 9

Atomic:

Atomic garantit que l'accès à la propriété sera effectué de manière atomique. Par exemple. il retourne toujours un objet entièrement initialisé, tout get/set d'une propriété sur un thread doit être terminé avant qu'un autre puisse y accéder.

Si vous imaginez que la fonction suivante se produise sur deux threads à la fois, vous pouvez voir pourquoi les résultats ne sont pas jolis.

-(void) setName:(NSString*)string
{
  if (name)
  {
    [name release]; 
    // what happens if the second thread jumps in now !?
    // name may be deleted, but our 'name' variable is still set!
    name = nil;
  }

  ...
}

Avantages: Le retour d'objets entièrement initialisés est le meilleur choix en cas de multi-threading.

Inconvénients: Les performances ont été ralenties, ce qui rend l'exécution un peu plus lente

Non Atomique:

Contrairement à Atomic, il ne garantit pas à chaque fois un retour d'objet initialisé complet.

Avantages: Exécution extrêmement rapide.

Inconvénients: Chances de déchet en cas de multi-threading.

Answer 10

Réponse la plus facile en premier: il n'y a pas de différence entre vos deux derniers exemples. Par défaut, les accesseurs de propriété sont atomiques.

Les accesseurs atomiques dans un environnement non récupéré (c'est-à-dire lors de l'utilisation de retenue/release/autorelease) utiliseront un verrou pour s'assurer qu'un autre thread n'interfère pas avec le réglage/obtention correct de la valeur.

Reportez-vous à la section " Performances et threads " de la documentation Objective-C 2.0 d’Apple pour plus d’informations et pour prendre en compte d’autres considérations lors de la création d’applications multithreads.

Answer 11

Atomic signifie qu'un seul thread accède à la variable (type statique). Atomic est thread-safe, mais c'est lent.

Nonatomic signifie que plusieurs threads ont accès à la variable (type dynamique). Nonatomic est dangereux pour la lecture, mais rapide.

Answer 12

Atomic est thread safe , il est lent et il assure bien (non garanti) que seule la valeur verrouillée est fournie, quel que soit le nombre de threads essayant d'accéder à la même zone. Lorsque vous utilisez atomic, un morceau de code écrit à l'intérieur de cette fonction devient la partie de la section critique, sur laquelle un seul thread peut s'exécuter à la fois.

Cela assure seulement la sécurité du fil; cela ne garantit pas cela. Ce que je veux dire, c'est que vous embauchez un pilote expert pour votre voiture, cela ne garantit pas pour autant que la voiture ne rencontrera pas d'accident. Cependant, la probabilité reste la moindre.

Atomic - il ne peut pas être décomposé, le résultat est donc attendu. Avec nonatomic - lorsqu'un autre thread accède à la zone mémoire, il peut la modifier, ce qui rend le résultat inattendu.

Code Talk: 

Atomic make getter et setter de la propriété thread safe. par exemple si tu as écrit: 

self.myProperty = value;

est thread-safe. 

[myArray addObject:@"Abc"] 

n'est pas thread-safe. 

Answer 13

Il n'y a pas de mot clé "atomique"

@property(atomic, retain) UITextField *userName;

Nous pouvons utiliser ce qui précède comme

@property(retain) UITextField *userName;

Voir la question relative au débordement de pile Je rencontre des problèmes si j'utilise @property (atomic, keep) NSString * myString.

Answer 14

Le default est atomic, cela signifie que vous perdez en performance lorsque vous utilisez la propriété, mais elle est thread-safe. Objective-C définit un verrou afin que seul le thread réel puisse accéder à la variable, à condition que le setter/getter soit exécuté. 

Exemple avec MRC d'une propriété avec un ivar _internal:

[_internal lock]; //lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;

Donc, ces deux derniers sont les mêmes:

@property(atomic, retain) UITextField *userName;

@property(retain) UITextField *userName; // defaults to atomic

nonatomic n’ajoute rien à votre code. Il n’est donc thread-safe que si vous codez vous-même le mécanisme de sécurité.

@property(nonatomic, retain) UITextField *userName;

Les mots-clés ne doivent pas du tout être écrits en tant que premier attribut de propriété.

N'oubliez pas, cela ne signifie pas que la propriété dans son ensemble est thread-safe. Seul l'appel de méthode du setter/getter est. Mais si vous utilisez un setter et ensuite un getter en même temps avec 2 threads différents, il pourrait également être cassé!

Answer 15

atomique (par défaut)

Atomic est la valeur par défaut: si vous ne tapez rien, votre propriété est atomique. Une propriété atomique est garantie que si vous essayez de lire à partir de vous obtiendrez une valeur valide. Il ne fait aucune garantie sur ce que pourrait être cette valeur, mais vous obtiendrez de bonnes données, pas juste de la mémoire indésirable. Qu'est-ce que cela vous permet de faire, c'est si vous avez plusieurs threads ou plusieurs processus pointant vers une seule variable, une thread peut lire et un autre thread peut écrire. S'ils frappent au même temps, le lecteur est assuré d’obtenir l’une des deux valeurs suivantes: soit avant le changement ou après le changement. Ce que l'atome ne fait pas Vous donner une garantie quant à laquelle de ces valeurs vous pourrait obtenir. Atomic est très souvent confondu avec le thread-safe, et ce n'est pas correct. Vous devez garantir la sécurité de votre fil d'autres moyens. Cependant, atomic garantira que si vous essayez de lire, vous récupérez une sorte de valeur.

non atomique

D'un autre côté, non-atomique, comme vous pouvez probablement le deviner, signifie simplement, "Ne fais pas ce genre de choses atomique." Ce que vous perdez, c'est cette garantie que vous toujours récupérer quelque chose. Si vous essayez de lire au milieu d'un écrire, vous pourriez récupérer des données erronées. Mais, d'un autre côté, vous y allez un peu plus vite. Parce que les propriétés atomiques doivent faire de la magie pour vous garantir de récupérer une valeur, ils sont un peu plus lents. Si c'est une propriété à laquelle vous accédez beaucoup, vous pouvez laisser tomber jusqu’à nonatomic pour vous assurer que vous ne subissez pas cette vitesse peine.

Voir plus ici: https://realm.io/news/tmi-objective-c-property-attributes/

Answer 16

Si vous utilisez votre propriété dans un code multi-thread, vous pourrez voir la différence entre les attributs non atomiques et atomiques. Nonatomic est plus rapide que atomique et atomique est thread-safe, pas nonatomique.

Vijayendra Tripathi a déjà donné un exemple pour un environnement multi-thread.

Answer 17

• -Atomic signifie qu'un seul thread accède à la variable (type statique).
• -Atomic est thread-safe.
• -mais sa performance est lente

Comment déclarer:

Comme atomique est la valeur par défaut,

@property (retain) NSString *name;

ET dans le fichier d'implémentation

self.name = @"sourov";

Supposons qu'une tâche liée à trois propriétés soit

 @property (retain) NSString *name;
 @property (retain) NSString *A;
 @property (retain) NSString *B;
 self.name = @"sourov";

Toutes les propriétés fonctionnent en parallèle (comme de manière asynchrone). 

Si vous appelez "name" à partir du fil A, 

Et 

En même temps si vous appelez 

[self setName:@"Datta"]

à partir du fil B, 

Now Si la propriété * name est nonatomic alors 

• Il retournera la valeur "Datta" pour A
• Il retournera la valeur "Datta" pour B

C’est pourquoi non atomic est appelé thread unsafe, mais il est rapide en performance à cause de l’exécution en parallèle 

Maintenant, si la propriété * name est atomique

• Il assurera la valeur "Sourov" pour A
• Ensuite, il retournera la valeur "Datta" pour B

C'est pourquoi atomic s'appelle thread Safe et c'est pourquoi on l'appelle coffre-fort en lecture-écriture

Une telle opération sera effectuée en série . Et lente performance

- Nonatomic signifie que plusieurs threads ont accès à la variable (type dynamique).

- Nonatomic est un fil dangereux.

- mais sa performance est rapide

-Nonatomic n'est PAS un comportement par défaut, nous devons ajouter un mot clé nonatomic dans l'attribut de propriété.

Pour In Swift Confirmation que les propriétés de Swift sont non atomiques au sens de ObjC. Une des raisons est que vous vous demandez si l'atomicité par propriété est suffisante pour vos besoins.

Référence: https://forums.developer.Apple.com/thread/25642

Pour plus d’informations, visitez le site Web http://rdcworld-iphone.blogspot.in/2012/12/variable-property-attributes-or.html

Answer 18

La propriété atomic garantit de conserver une valeur totalement initialisée, quel que soit le nombre de threads effectuant la lecture et la définition sur celle-ci. 

La propriété nonatomic spécifie que les accesseurs synthétisés définissent ou renvoient directement une valeur directement, sans aucune garantie sur ce qu'il se passera si la même valeur est accédée simultanément à partir de différents threads.

Answer 19

Atomic signifie qu'un seul thread peut accéder à la variable à la fois (type statique). Atomic est thread-safe, mais c'est lent.

Non atomique signifie que plusieurs threads peuvent accéder à la variable en même temps (type dynamique). Nonatomic est dangereux pour la lecture, mais rapide.

Answer 20

Si vous utilisez atomic, cela signifie que le thread sera sécurisé et en lecture seule. Si vous utilisez nonatomic, cela signifie que plusieurs threads accèdent à la variable et que celle-ci est non sécurisée, mais que l'exécution est rapide, qu'il s'agisse d'opérations de lecture et d'écriture. c'est un type dynamique.

Answer 21

Propriétés atomiques : - Quand une variable est affectée avec la propriété atomique, ce qui signifie qu'elle ne dispose que d'un seul accès à un thread; elle sera thread-safe et performante du point de vue des performances. Elle aura un comportement par défaut.

Non Atomic Properties : - Quand une variable affectée avec la propriété atomic, ce qui signifie qu'elle dispose d'un accès multi-thread, qu'elle ne sera pas thread-safe et qu'elle sera lente en termes de performances, aura un comportement par défaut et lorsque deux threads différents voudront y accéder. variable en même temps, il donnera des résultats inattendus.

Answer 22

(Atomicity Atomic (default)} _

La valeur par défaut est Atomic: si vous ne tapez rien, votre propriété est atomique. Une propriété atomique est garantie que si vous essayez de la lire, vous obtiendrez une valeur valide. Cela ne garantit en rien ce que pourrait être cette valeur, mais vous obtiendrez de bonnes données, pas seulement de la mémoire indésirable. Cela vous permet de faire si vous avez plusieurs threads ou plusieurs processus pointant sur une seule variable, un thread peut lire et un autre thread peut écrire. S'ils frappent en même temps, le lecteur aura sûrement l'une des deux valeurs: avant ou après le changement. Atomic ne vous donne pas une quelconque garantie sur les valeurs que vous pourriez obtenir. Atomic est souvent confondu avec le thread-safe, et ce n’est pas correct. Vous devez garantir la sécurité de votre fil par d'autres moyens. Cependant, atomic garantira que si vous essayez de lire, vous récupérez une sorte de valeur.

non atomique

D'un autre côté, non-atomique, comme vous pouvez probablement le deviner, signifie simplement «ne faites pas ce genre de choses atomique». Ce que vous perdez, c'est la garantie que vous récupérerez toujours quelque chose. Si vous essayez de lire au milieu d'une écriture, vous pourriez récupérer des données erronées. Mais, d'un autre côté, vous allez un peu plus vite. Parce que les propriétés atomiques doivent faire un peu de magie pour garantir que vous récupériez une valeur, elles sont un peu plus lentes. S'il s'agit d'une propriété à laquelle vous accédez beaucoup, vous pouvez choisir de passer à nonatomic pour vous assurer de ne pas encourir cette pénalité de vitesse .

courtoisie https://academy.realm.io/posts/tmi-objective-c-property-attributes/

Les attributs de propriété Atomicity (atomiques et non atomiques) ne sont pas reflétés dans la déclaration de propriété Swift correspondante, mais les garanties d'atomicité de l'implémentation Objective-C sont toujours valables lorsque la propriété importée est accessible depuis Swift.

So - si vous définissez une propriété atomique dans Objective-C, elle restera atomique si elle est utilisée par Swift.

courtoisie https://medium.com/@YogevSitton/atomic-vs-non-atomic-properties-crash-course-d11c23f4366c

Answer 23

Pour simplifier toute la confusion, comprenons le verrou mutex.

Le verrou mutex, conformément au nom, verrouille la mutabilité de l'objet. Ainsi, si une classe a accès à l'objet, aucune autre classe ne peut accéder au même objet.

Dans iOS, @sychronise fournit également le verrou mutex. Il sert maintenant en mode FIFO et garantit que le flux n'est pas affecté par deux classes partageant la même instance. Toutefois, si la tâche est sur le thread principal, évitez d'accéder à l'objet à l'aide de propriétés atomiques, car cela risquerait de contenir votre interface utilisateur et de dégrader les performances.

Answer 24

Atomic: Assurez la sécurité du fil en le bloquant à l'aide de NSLOCK.

Non atomique: n'assure pas la sécurité du thread car il n'y a pas de mécanisme de blocage du thread.

Answer 25

La vérité est qu'ils utilisent spin lock pour implémenter la propriété atomique. Le code ci-dessous:

 static inline void reallySetProperty(id self, SEL _cmd, id newValue, 
      ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy) 
    {
        id oldValue;
        id *slot = (id*) ((char*)self + offset);

        if (copy) {
            newValue = [newValue copyWithZone:NULL];
        } else if (mutableCopy) {
            newValue = [newValue mutableCopyWithZone:NULL];
        } else {
            if (*slot == newValue) return;
            newValue = objc_retain(newValue);
        }

        if (!atomic) {
            oldValue = *slot;
            *slot = newValue;
        } else {
            spin_lock_t *slotlock = &PropertyLocks[GOODHASH(slot)];
            _spin_lock(slotlock);
            oldValue = *slot;
            *slot = newValue;        
            _spin_unlock(slotlock);
        }

        objc_release(oldValue);
    }