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

https://stackoverflow.com/questions/588866

09-09-2019
|

Question

Qu'est-ce que atomic et nonatomic signifient 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?

La solution

Les deux derniers sont identiques; « Atomique » est le comportement par défaut ( Notez qu'il est pas vraiment un mot-clé, il est précisé que par l'absence de nonatomic - atomic a été ajouté comme mot clé dans les versions récentes de LLVM / clang).

En supposant que vous @synthesizing les implémentations de méthode, atomiques par rapport aux changements non atomiques du code généré. Si vous écrivez votre propre setter / getter, atomique / nonatomic / conserver / assign / copy sont simplement consultatif. (Note: @synthesize est maintenant le comportement par défaut dans les versions récentes de LLVM Il n'y a pas non plus besoin de déclarer des variables d'instance, ils seront synthétisés automatiquement, aussi, et aura un _ préfixé à leur nom pour empêcher l'accès accidentel direct.).

, le setter / getter synthétisé « atomique » veillera à ce que ensemble valeur est toujours renvoyée du getter ou réglé par le régleur, quelle que soit l'activité setter sur tout autre fil. Autrement dit, si le thread A est au milieu du getter alors que le thread B appelle le poseur, une valeur réelle viable - un objet autoreleased, le plus probable -. Sera retourné à l'appelant dans A

Dans nonatomic, pas de telles garanties sont faites. Ainsi, nonatomic est nettement plus rapide que "atomique".

Qu'est-ce que « atomique » fait pas faire est de faire aucune garantie sur la sécurité fil. Si le thread A appelle le getter simultanément avec du fil B et C appelant le compositeur avec des valeurs différentes, le thread A peut obtenir une des trois valeurs retournées - une avant tout setters être appelé ou l'une des valeurs transmises dans les setters dans B et C. de même, l'objet peut se retrouver avec la valeur de B ou C, aucun moyen de savoir.

Assurer l'intégrité des données - l'un des principaux défis de la programmation multi-thread -. Est atteint par d'autres moyens

Ajout à ceci:

atomicity d'une propriété unique aussi ne peut pas garantir la sécurité des threads lorsque les propriétés dépendantes multiples sont en jeu.

Considérez:

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

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

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 qui permet d'exclure l'accès à fullName tandis que les propriétés dépendantes sont mises à jour.

Autres conseils

Ceci est expliqué dans Apple href="http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html" , mais au-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 « nonatomic » alors la propriété est atomique, mais en spécifiant « atomique » sera explicitement le résultat d'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é:

//@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_;
    }
}

En fait, la version atomique doit prendre une serrure afin de garantir la sécurité du fil, et est également heurtant le compte de référence sur l'objet (et le nombre de autorelease pour l'équilibrer) afin que l'objet est garanti d'exister pour l'appelant , sinon il y a une condition de course potentielle si un autre thread réglage de la valeur, ce qui provoque le nombre de ref tomber à 0.

Il y a en fait un grand nombre de différentes variantes de la façon dont ces choses fonctionnent selon que les propriétés sont des valeurs scalaires ou des objets, et comment conserver, copier, en lecture seule, nonatomic, etc interagir. En général, les synthétiseurs de propriété savent exactement comment faire la « bonne chose » pour toutes les combinaisons.

atomique

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

Non-atomique

est pas le comportement par défaut
plus rapide (pour le code synthétisé, qui est, pour les variables créées à l'aide @property et @synthesize)
pas thread-safe
peut entraîner un comportement inattendu, lorsque deux accès processus différent de la même variable en même temps

La meilleure façon de comprendre la différence est dans l'exemple suivant.

Supposons qu'il y ait une propriété de chaîne atomique appelée « nom », et si vous appelez [self setName:@"A"] de fil A, appelez [self setName:@"B"] de fil B et appeler [self name] de fil C, toutes les opérations sur différents threads seront effectués en série qui signifie que si un fil exécute un setter ou getter, puis d'autres threads attendront.

Cela rend la propriété « nom » lecture / écriture en toute sécurité, mais si un autre thread, D, appelle [name release] simultanément alors cette opération pourrait produire un accident parce qu'il n'y a pas d'appel setter / getter impliqué ici. Ce qui signifie un objet est en lecture / écriture en toute sécurité (ATOMIQUE), mais pas thread-safe comme un autre fils peuvent envoyer simultanément tout type de messages à l'objet. Le développeur doit assurer la sécurité des threads pour ces objets.

Si la propriété « nom » était nonatomic, tous les fils dans l'exemple ci-dessus - A, B, C et D exécuteront produire simultanément un résultat imprévisible. En cas de atomique, soit l'un de A, B ou C exécutera premier, mais D peut encore exécuter en parallèle.

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

Quelle est la différence fonctionnelle entre ces 3?

Je considérais toujours atomique comme défaut tout à fait curieux. Au niveau d'abstraction, nous travaillons à l'aide des propriétés atomiques pour une classe en tant que véhicule pour atteindre la sécurité des threads 100% est un cas d'angle. Pour les programmes multithread vraiment corrects, l'intervention du programmeur est presque certainement une exigence. Pendant ce temps, les caractéristiques de performance et de l'exécution n'a pas encore été détaillées en profondeur. Après avoir écrit quelques programmes très multithread au fil des ans, j'avais déclarais mes propriétés comme nonatomic tout le temps parce que atomique n'a pas été raisonnable à des fins. Au cours de la discussion des détails des propriétés atomiques et cette non atomiques question , j'ai fait quelques profilage rencontré quelques résultats curieux.

Exécution

Ok. La première chose que je voudrais éclaircir est que la mise en œuvre de verrouillage est mise en œuvre définie et abstraire. Louis utilise @synchronized(self) dans son exemple - je l'ai vu comme une source commune de confusion. La mise en œuvre ne fonctionne pas en fait utilisation @synchronized(self); il utilise le niveau d'objet spin locks . L'illustration de Louis est bon pour une illustration de haut niveau en utilisant des constructions que nous connaissons tous, mais il est important de savoir qu'il n'utilise pas @synchronized(self).

Une autre différence est que les propriétés atomiques conserveront / cycle de sortie de vos objets dans le getter.

Performance

Voici la partie intéressante: la performance en utilisant la propriété atomique accès dans incontesté (par exemple monothread) les cas peuvent être vraiment très rapide dans certains cas. Dans moins de cas idéal, l'utilisation des accès atomiques peut coûter plus de 20 fois les frais généraux de nonatomic. Bien que le attaqué 7 cas en utilisant des fils était de 44 fois plus lente pour le struct trois octets (2,2 GHz Core i7 Quad-Core , x86_64). Le struct trois octets est un exemple d'une propriété très lente.

note intéressante: accesseurs définies par l'utilisateur du struct trois octets ont été 52 fois plus rapide que les accesseurs atomiques synthétisés; ou 84% de la vitesse de synthèse non atomiques accesseurs.

Les objets dans les cas litigieux peuvent dépasser 50 fois.

En raison du nombre d'optimisations et des variations dans les implémentations, il est assez difficile de mesurer les impacts réels dans ces contextes. Vous pouvez souvent entendre quelque chose comme « Faites confiance à moins que vous le trouverez profil et est un problème ». En raison du niveau d'abstraction, il est en fait assez difficile de mesurer l'impact réel. Glanant les coûts réels de profils peut prendre beaucoup de temps, et en raison des abstractions, tout à fait inexact. De plus, ARC vs MRC peut faire une grande différence.

Alors Remontons, pas mettant l'accent sur la mise en œuvre de la propriété accès, nous allons inclure les suspects habituels comme objc_msgSend, et d'examiner des réels résultats de haut niveau pour de nombreux appels à un NSString getter dans incontestées cas (valeurs en secondes):

MRC | nonatomic | getters manuellement mis en oeuvre: 2
MRC | nonatomic | synthétisé getter: 7
MRC | atomique | synthétisé getter: 47
ARC | nonatomic | synthétisé getter: 38 (note: nombre d'ARC ajoutant ref cyclisme ici)
ARC | atomique | synthétisé getter: 47

Comme vous l'avez sans doute deviné, l'activité de comptage de référence / vélo est un facteur important avec Atomics et sous ARC. Vous verriez aussi greatedifférences r dans les cas litigieux.

Bien que je fais attention à la performance, je dis encore Sémantique d'abord! . Pendant ce temps, la performance est une priorité pour de nombreux projets. Cependant, connaître les détails d'exécution et les coûts des technologies que vous utilisez certainement ne fait pas mal. Vous devez utiliser la technologie adaptée à vos besoins, les objectifs et les capacités. Si tout va bien, cela vous fera économiser quelques heures de comparaisons, et vous aider à prendre une décision plus éclairée lors de la conception de vos programmes.

atomique = fil de sécurité

Non-atomique = Pas de fil de sécurité

Sécurité du thread:

Les variables d'instance sont thread-safe si elles se comportent correctement lorsque accessible à partir de plusieurs threads, quelle que soit la planification ou l'entrelacement de l'exécution de ces discussions par l'environnement d'exécution, et sans synchronisation supplémentaire ou toute autre coordination de la part de l'appel code.

Dans notre contexte:

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

Où utiliser `atomic`:

si la variable d'instance va être accessible dans un environnement multithread.

Implication de `atomic`:

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

Où utiliser `nonatomic`:

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

J'ai trouvé une explication assez bien mettre des propriétés atomiques et non atomiques

Après avoir lu tant d'articles, Stack messages de débordement et de faire des applications de démonstration pour vérifier les attributs de propriété variables, j'ai décidé de mettre toutes les informations d'attributs ainsi:

atomic // Par défaut
nonatomic
strong = retain // Par défaut
weak = unsafe_unretained
retain
assign // Par défaut
unsafe_unretained
copy
readonly
readwrite // Par défaut

Dans l'article attributs propriété variable ou modificateurs dans iOS vous pouvez trouver tous les attributs mentionnés ci-dessus, et qui vous aidera certainement.

atomic
- atomic signifie un seul accès de fil de la variable (type statique).
- atomic est thread-safe.
- Mais il est lent dans la performance
- atomic est le comportement par défaut
- accesseurs atomique dans un environnement non collecté des déchets (à savoir lors de l'utilisation de retenir / libération / autorelease) utilisera un verrou pour assurer qu'un autre thread ne pas interférer avec le bon réglage / obtenir de la valeur.
- Il est pas vraiment un mot-clé.
Exemple:
```
    @property (retain) NSString *name;

    @synthesize name;
```
nonatomic
- nonatomic signifie accès multiple par fil de la variable (de type dynamique).
- nonatomic est thread-dangereux.
- Mais il est rapide dans la performance
- nonatomic n'est pas le comportement par défaut. Nous devons ajouter le mot-clé nonatomic dans l'attribut de la propriété.
- Il peut en résulter un comportement inattendu, lorsque deux processus différents (threads) accèdent à la même variable dans le même temps.
Exemple:
```
    @property (nonatomic, retain) NSString *name;

    @synthesize name;
```

atomique:

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

Si vous imaginez la fonction suivante se produisant sur deux threads à la fois, vous pouvez voir pourquoi les résultats ne seraient pas assez.

-(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: Retour d'objets entièrement initialisés chaque fois en fait le meilleur choix en cas de multi-threading.

Inconvénients: Performance coup, rend l'exécution un peu plus lent

Non-atomique:

Contrairement atomique, il ne garantit pas l'objet complètement initialisés revenir à chaque fois.

Avantages: exécution extrêmement rapide.

Inconvénients: Les chances de la valeur des déchets en cas de multi-threading.

La première réponse Easiest: Il n'y a pas de différence entre vos deux deuxièmes exemples. Par défaut, accesseurs de propriété sont atomiques.

accesseurs atomique dans un environnement non collecté des déchets (à savoir lors de l'utilisation de retenir / libération / autorelease) utilisera un verrou pour assurer qu'un autre thread ne pas interférer avec le bon réglage / obtenir de la valeur.

Voir la « Performance et Threading » section de la documentation Objective-C 2.0 d'Apple pour un peu plus d'informations et pour d'autres considérations lors de la création des applications multi-thread.

signifie un seul fil atomique accède à la variable (type statique). Atomique est thread-safe, mais il est lent.

nonatomic signifie plusieurs threads accéder à la variable (type dynamique). Nonatomic est thread-dangereux, mais il est rapide.

atomique est thread-safe , il est lent et il bien-assure (non garanti) que seule la valeur verrouillée est prévue, peu importe nombre de threads tentent un accès sur la même zone. Lors de l'utilisation atomique, un morceau de code écrit à l'intérieur de cette fonction devient la partie de la section critique, à laquelle un seul fil peut exécuter à la fois.

Il assure que la sécurité de fil; il ne garantit pas que. Ce que je veux dire est que vous embauchez un pilote expert pour votre voiture, encore ne garantit voiture ne répondra pas à un accident. Cependant, la probabilité reste le moindre.

atomique - il ne peut pas être décomposé, de sorte que le résultat est attendu. Avec nonatomic -. Quand un autre accès fil de la zone de mémoire, il peut le modifier, de sorte que le résultat est inattendu

Code de conversation:

atomique faire getter et setter du fil de la propriété en toute sécurité. par exemple, si u ont écrit:

self.myProperty = value;

est thread-safe.

[myArray addObject:@"Abc"]

est pas sûre.

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

@property(atomic, retain) UITextField *userName;

Nous pouvons utiliser ce qui précède comme

@property(retain) UITextField *userName;

Voir la question Stack Overflow Je reçois des questions si j'utilise @property (atomique, conserver) NSString * myString .

par défaut est atomic, cela signifie qu'il vous ne coûte performances chaque fois que vous utilisez la propriété, mais il est thread-safe. Qu'est-ce que Objective-C, est fixé un verrou, de sorte que le fil réel peut accéder à la variable, tant que le setter / getter est exécuté.

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

[_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

Par contre ne nonatomic rien à ajouter à votre code. Il est donc seul fil en toute sécurité si vous codez mécanisme de sécurité vous.

@property(nonatomic, retain) UITextField *userName;

Les mots-clés ne doivent pas être écrit comme premier attribut de propriété du tout.

Ne pas oublier, cela ne signifie pas que la propriété dans son ensemble est thread-safe. Seul l'appel de la méthode du setter / getter est. Mais si vous utilisez un setter et après qu'un getter en même temps avec 2 fils différents, il pourrait être cassé aussi!

atomique (par défaut)

atomique est la valeur par défaut: si vous ne tapez rien, votre propriété est   atomique. Une propriété atomique est garanti que si vous essayez de lire à partir   il, vous récupérerez une valeur valide. Il ne fait aucune garantie   à ce que la valeur pourrait être, mais vous récupérerez les bonnes données, et non   juste mémoire indésirable. Cela vous permet de faire est si vous avez plusieurs   fils ou plusieurs processus de pointage à une seule variable, l'un   fil peut lire et un autre thread peut écrire. S'ils ont frappé à la   temps, le fil du lecteur est assuré d'obtenir l'une des deux valeurs:   soit avant le changement ou après le changement. Qu'est-ce pas atomique   vous donner est une sorte de garantie dont ces valeurs que vous   pourrait obtenir. Atomique est vraiment souvent confondu avec être thread-safe,   et ce n'est pas correct. Vous devez garantir votre sécurité fil   d'autres moyens. Cependant, atomique garantit que si vous essayez de lire,   vous revenez une sorte de valeur.

nonatomic

Du côté de la médaille, non atomique, comme vous pouvez probablement le deviner, signifie simplement que,   « Ne fais pas ce genre de choses atomique. » Ce que vous perdez est cette garantie que vous   toujours obtenir quelque chose en retour. Si vous essayez de lire au milieu d'un   écrire, vous pouvez récupérer les données d'ordures. Mais, d'autre part, vous allez   un peu plus rapide. Parce que les propriétés atomiques doivent faire de la magie   pour garantir que vous récupérerez une valeur, ils sont un peu plus lent. Si   il est une propriété que vous accédez à beaucoup, vous voudrez peut-être laisser tomber   jusqu'à nonatomic pour vous assurer que vous n'êtes pas encourir cette vitesse   pénalité.

Voir plus ici: https://realm.io/news/tmi-objective-c- propriété-attributs /

Si vous utilisez votre propriété dans le code multi-thread, vous seriez en mesure de voir la différence entre les attributs et non atomiques atomiques. Nonatomic est plus rapide que atomique et atomique est thread-safe, pas nonatomic.

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

-Atomic signifie un seul accès de fil de la variable (type statique).
-Atomic est thread-safe.
-mais il est lent dans la performance

Comment déclarer:

Comme atomique est donc défaut,

@property (retain) NSString *name;

dans le fichier de mise en œuvre

self.name = @"sourov";

Supposons une tâche liée à trois propriétés sont

 @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 manière asynchrone).

Si vous appelez "nom" de fil ,

En même temps, si vous appelez

[self setName:@"Datta"]

de fil B

Si maintenant * propriété name est nonatomic puis

Il valeur de retour "Datta" A
Il retourne la valeur "Datta" B

C'est pourquoi non atomique est appelé fil dangereux Mais, mais il est rapide dans l'exécution en raison de l'exécution en parallèle

Si maintenant * propriété de nom est atomique

Il assurera la valeur "Sourov" A
Ensuite, il valeur de retour "Datta" B

Voilà pourquoi atomique est appelé thread-safe C'est pourquoi il est appelé en lecture-écriture en toute sécurité

Une telle opération de la situation se produira en série. et lent dans la performance

- nonatomic signifie accès multiple du fil de la variable (de type dynamique)

- nonatomic est thread dangereux

- mais il est rapide dans la performance

-Nonatomic est pas par défaut le comportement, nous avons besoin d'ajouter mot-clé nonatomic dans l'attribut de la propriété.

Pour Swift Confirmant que les propriétés Swift sont nonatomic au sens ObjC. L'une des raisons est si vous pensez que atomicité par propriété est suffisant pour vos besoins.

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

Fro plus d'informations s'il vous plaît visitez le site Web http://rdcworld-iphone.blogspot.in/ 2012/12 / variable propriété-attributs-or.html

Avant de commencer: Vous devez savoir que chaque objet en mémoire doit être désallouée de la mémoire pour un nouvel auteur se produise. Vous ne pouvez pas tout simplement écrire sur le dessus de quelque chose que vous faites sur le papier. Vous doit d'abord effacer (dealloc) et ensuite vous pouvez écrire sur elle. Si au moment où l'effacement est fait (ou la moitié fait) et rien n'a pas encore été écrit (ou demi écrit) et que vous essayez de le lire pourrait être très problématique! aide atomique et nonatomic vous traiter ce problème de différentes manières.

Mais lisez d'abord cette question puis lire réponse de Bbum. De plus, alors lisez mon résumé.

atomic sera toujours garantie

Si deux personnes différentes veulent lire et écrire en même temps, votre papier ne sera pas seulement brûler! -.> Votre demande ne sera jamais tomber en panne, même dans une condition de course
Si une personne tente d'écrire et a écrit seulement 4 des 8 lettres à écrire, alors ne peut lire au milieu, la lecture ne peut se faire lorsque les 8 lettres est écrit -> Pas de lecture (get) qui va se passer sur « un fil qui est en train d'écrire encore », à savoir s'il y a 8 octets à octets à écrire, et seulement 4 octets sont écrits - jusqu'à ce moment-là, vous n'êtes pas autorisé à lire. Mais puisque je l'ai dit ne plantera pas, il se lirait alors de la valeur d'un autoreleased objet.
Si avant Vous ce qui a été effacé précédemment écrit sur papier, puis quelqu'un veut vous lire peut lire encore. Comment? Vous serez en train de lire quelque chose de similaire à bin Trash Mac OS (comme bac à ordures ne sont pas encore 100% effacé ... il est dans les limbes) ---> Si ThreadA est à lire en ThreadB a déjà deallocated d'écrire, vous obtiendrez une valeur de la valeur soit entièrement écrite finale par ThreadB ou obtenir quelque chose de la piscine autorelease.

Retain compte sont la façon dont la mémoire est gérée en Objective-C. Lorsque vous créez un objet, il a un nombre de conserver 1. Lorsque vous envoyez un objet de conserver un message, son état de comptage est incrémenté de conserver 1. Lorsque vous envoyez un objet un message de libération, son compte retenir est décrémenté par 1. Lorsque vous envoyez un objet un, le nombre de conserver message autorelease est décrémenté par 1 à un certain moment dans l'avenir. Si un object's conservent le nombre est réduit à 0, il est désalloué.

Atomic ne pas garantir la sécurité de fil, mais il est utile pour parvenir à la sécurité des threads. Sécurité des threads est par rapport à la façon dont vous écrivez votre code / file d'attente qui vous fil de lecture / écriture de. Il ne garantit que multithreading non crashable.

Quoi ?! Sont multithreading et la sécurité des threads différent?

Oui. Multithreading signifie: plusieurs threads peuvent lire un morceau partagé de données en même temps et nous ne plantera pas, mais il ne garantit pas que vous n'êtes pas en train de lire une valeur non autoreleased. Avec la sécurité du fil, il est garanti que ce que vous lisez est pas publié automatiquement. La raison pour laquelle nous ne faisons pas tout atomique par défaut est, qu'il ya un coût de performance et pour la plupart des choses ne sécurité pas vraiment besoin de fil. Quelques parties de notre code ont besoin et pour les quelques parties, nous devons écrire notre code d'une manière thread-safe en utilisant des serrures, mutex ou la synchronisation.

nonatomic

Comme il n'y a pas une telle chose comme Mac OS Corbeille, puis personne ne se soucie que d'obtenir une valeur ou non toujours (<- Cela pourrait conduire à un accident), ni personne se soucie si quelqu'un essaie de lire la moitié de votre écrit (bien que l'écriture à mi-chemin dans Memory est très différent de l'écriture à mi-chemin sur le papier, sur la mémoire, il pourrait vous donner une valeur stupide folle d'avant, alors que sur le papier que vous voyez seulement la moitié de ce qui a été écrit) -> ne garantit pas de ne pas tomber en panne, car il n » t mécanisme utilisé autorelease.
Ne garantit pas les valeurs écrites complètes à lire!
est plus rapide que atomique

Dans l'ensemble ils sont différents dans 2 aspects:

ou non Crashing à cause d'avoir ou ne pas avoir une piscine autorelease.
Permettre à lire au milieu d'un « pas encore fini d'écriture ou de valeur vide » ou ne permettant pas et ne permettant de lire lorsque la valeur est complètement écrit.

La propriété atomique assure de conserver une valeur pleinement initialisés quel que soit le nombre de threads font getter et setter sur elle.

La propriété nonatomic précise que synthétisé accesseurs simplement définir ou renvoyer une valeur directement, sans aucune garantie sur ce qui se passe si cette même valeur est accessible simultanément à partir de différents threads.

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

nonatomic signifie plusieurs threads peuvent accéder à la variable en même temps (de type dynamique). Nonatomic est thread-dangereux, mais il est rapide.

atomicité atomique (par défaut)

atomique est la valeur par défaut: si vous ne tapez rien, votre propriété est atomique. Une propriété atomique est garanti que si vous essayez de lire à partir il, vous récupérerez une valeur valide. Il ne fait aucune garantie à ce que la valeur pourrait être, mais vous récupérerez les bonnes données, et non juste mémoire indésirable. Cela vous permet de faire est si vous avez plusieurs fils ou plusieurs processus de pointage à une seule variable, l'un fil peut lire et un autre thread peut écrire. S'ils ont frappé à la temps, le fil du lecteur est assuré d'obtenir l'une des deux valeurs: soit avant le changement ou après le changement. Qu'est-ce pas atomique vous donner est une sorte de garantie dont ces valeurs que vous pourrait obtenir. Atomique est vraiment souvent confondu avec être thread-safe, et ce n'est pas correct. Vous devez garantir votre sécurité fil d'autres moyens. Cependant, atomique garantit que si vous essayez de lire, vous revenez une sorte de valeur.

nonatomic

Du côté de la médaille, non atomique, comme vous pouvez probablement le deviner, signifie simplement que, « Ne fais pas ce genre de choses atomique. » Ce que vous perdez est cette garantie que vous toujours obtenir quelque chose en retour. Si vous essayez de lire au milieu d'un écrire, vous pouvez récupérer les données d'ordures. Mais, d'autre part, vous allez un peu plus rapide. Parce que les propriétés atomiques doivent faire de la magie pour garantir que vous récupérerez une valeur, ils sont un peu plus lent. Si il est une propriété que vous accédez à beaucoup, vous voudrez peut-être laisser tomber jusqu'à nonatomic pour vous assurer que vous n'êtes pas encourir cette vitesse peine. L'accès

https://academy.realm.io/posts / TMI-c-propriété-objectif-attributs /

attributs de propriété d'atomicité (atomiques et non atomiques) ne sont pas reflétés dans la déclaration de propriété Swift correspondante, mais les garanties atomicité de la mise en œuvre Objective-C détiennent encore lorsque la propriété importée est accessible à partir de Swift.

Alors -. Si vous définissez une propriété atomique en Objective-C, il demeurera atomique quand il est utilisé par Swift

courtoisie https://medium.com/@YogevSitton/ atomiques-contre-non-atomiques-propriétés-crash-cours-d11c23f4366c

Si vous utilisez atomique, cela signifie que le fil sera en sécurité et en lecture seule. Si vous utilisez nonatomic, cela signifie que les multiples threads d'accéder à la variable et fil à risque, mais il est exécuté rapidement, fait une lecture et d'écriture; c'est un type dynamique.

La vérité est qu'ils utilisent verrou de rotation pour mettre en œuvre 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);
    }

Propriétés atomiques : -. Lorsqu'une variable attribuée à la propriété atomique qui signifie qu'il n'a qu'un seul accès fil et il sera thread-safe et sera bon en perspective de performance, aura un comportement par défaut

Propriétés non atomique : - Lorsqu'une variable attribuée à la propriété atomique qui signifie qu'il a accès multi thread et il ne sera pas thread-safe et sera lente en perspective de performance, aura un comportement par défaut et quand deux variables veulent accéder à différents threads en même temps, il donnera des résultats inattendus.

Pour simplifier toute confusion, laissez-nous comprendre mutex.

verrou mutex, selon le nom, verrouille la mutabilité de l'objet. Donc, si l'objet est accessible par une classe, aucune autre classe peut accéder au même objet.

Dans iOS, @sychronise fournit également le mutex .Maintenant il sert en mode FIFO et assure le flux est pas affectée par deux classes partageant la même instance. Cependant, si la tâche est thread principal, éviter l'accès à l'aide des propriétés objet atomiques car il peut contenir votre interface utilisateur et dégrader les performances.

atomique. Veiller à ce fil de sécurité en bloquant le fil à l'aide NSLOCK

Non atomique. Ne garantit pas la sécurité-fil car il n'y a pas de mécanisme de verrouillage fil

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow