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

Ceci est expliqué dans Apple la documentation , 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 provoquer 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_;
    }
}

Fondamentalement, 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 est 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
• n'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 conduire à un comportement inattendu, lorsque deux processus différents accès à la même variable en même temps

La meilleure façon de comprendre la différence utilise 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, appel [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 ce qui signifie que si un thread 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 en [name release]même temps alors cette opération peut 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 l' exécution et les 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 à, en utilisant les 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 que nonatomictout 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 non atomiques cette question , je l' ai fait un certain profilage a rencontré des résultats curieux.

Exécution

D'accord. 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 fait utiliser @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 à incontestées (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ée cas à l' aide de 7 fils était 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 étaient 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 la « confiance, à moins que vous profil et trouvez 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 revenons en arrière, ne pas se concentrer sur la mise en œuvre de la propriété des accès, nous vous ferons parvenir les suspects habituels comme objc_msgSend, et d' examiner quelques réels résultats de haut niveau pour de nombreux appels à un NSStringgetter 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é compte de référence / vélo est un facteur important avec Atomics et sous ARC. Vous verriez aussi des différences plus importantes dans les cas litigieux.

Même si 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. Espérons que cela vous fera économiser quelques heures de comparaisons, et vous aider à prendre une décision mieux informée lors de la conception de vos programmes.

Atomique = sécurité fil

Non atomique = Pas de fil de sécurité

sécurité du fil:

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 fils par l'environnement d'exécution, et sans synchronisation supplémentaire ou toute autre coordination de la part du code d'appel.

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 nonatomicparce quenonatomic 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 ici . Voici un texte pertinent de la même:

« atomique » signifie qu'il ne peut pas être divisé. En ce qui concerne OS / de programmation d' un appel de fonction atomique est celui qui ne peut pas être interrompu - toute la fonction doit être exécutée, et non permuté de la CPU par le contexte habituel de l'OS de commutation jusqu'à ce qu'il soit terminé. Juste au cas où vous ne saviez pas: puisque le CPU ne peut faire qu'une chose à la fois, le système d' exploitation tourne l' accès à l'unité centrale de traitement à tous les processus en cours d' exécution en peu de temps des tranches, pour donner l' illusion de multi - tâches. Le programmateur du processeur peut (et fait) interrompre un processus à tout moment dans son exécution - même appel de fonction mi. Donc , pour des actions telles que la mise à jour des variables de compteur partagé où deux processus peuvent essayer de mettre à jour la variable en même temps, ils doivent être exécutés « atomiquement », à savoir, chaque action de mise à jour doit terminer dans son intégralité avant tout autre processus peut être échangé sur le CPU.

Je serais donc deviner que atomique dans ce cas signifie que les méthodes de lecture d'attributs ne peuvent pas être interrompus - en effet ce qui signifie que la variable (s) en cours de lecture par la méthode ne peut pas changer la moitié de la valeur chemin à travers, car un autre thread / appel / fonction obtient troqué sur le CPU.

Parce que les atomicvariables ne peuvent pas être interrompus, la valeur contenue par eux à tout moment est (thread-lock) garanti d'être incorruptible , bien que, en assurant ce verrou de fil rend leur accès plus lent. non-atomicles variables, d'autre part, ne font pas une telle garantie , mais offrent le luxe d' un accès plus rapide. Pour résumer, rendez - vous avec non-atomicquand vous savez que vos variables ne seront pas accessibles par plusieurs threads simultanément et accélérer les choses.

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 ensemble:

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

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

1. atomic

   • atomic un moyen un seul accès de fil de la variable (type statique).
   • atomic est thread-safe.
   • Mais il est lent à la performance
   • atomic est le comportement par défaut
   • accesseurs atomique dans un environnement non collecté des déchets (c.-à 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;
   

2. nonatomic

   • nonatomic des moyens d'accès multiple par fil de la variable (de type dynamique).
   • nonatomic est thread-dangereux.
   • Mais il est rapide dans la performance
   • nonatomicest pas par défaut le comportement. Nous devons ajouter le nonatomicmot - clé 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;
   

La première réponse facile: 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 (c.-à 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 d'Apple Objective-C 2.0 pour un peu plus d' informations » et pour d' autres considérations lors de la création des applications multi-thread.

atomique:

garanties atomiques que 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;
  }

  ...
}

Plus: Retour des objets entièrement initialisés chaque fois en fait le meilleur choix en cas de multi-threading.

Inconvénients: performance due , 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.

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

Nonatomic signifie plusieurs threads accèdent à la variable (de type dynamique). Nonatomic est thread-dangereux, mais il est rapide.

Atomique est thread - safe , il est lent et il bien-(non garanti assure) que seule la valeur est verrouillée à condition , peu importe combien 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 thread 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 Discuter:

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, retenir) NSString * myString .

La valeur par défaut est atomic, cela signifie qu'il ne vous coûte des performances lorsque 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 avec la MRC d'une propriété avec 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

D'autre part ne nonatomicrien ajouter à votre code. Il est donc seul fil en toute sécurité si vous codez mécanisme de sécurité vous - même.

@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, vous récupérerez une valeur valide. Il ne fait aucune garantie quant à ce que la valeur pourrait être, mais vous récupérerez de bonnes données, pas seulement la mémoire indésirable. Cela vous permet de faire est si vous avez plusieurs threads ou plusieurs processus pointant à une seule variable, un thread peut lire et un autre thread peut écrire. S'ils ont frappé en même 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 que atomique ne vous donne pas est une sorte de garantie dont ces valeurs que vous pourriez obtenir. Atomique est vraiment souvent confondu avec être thread-safe, et qui ne sont pas corrects. Vous devez garantir votre sécurité de 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 pas faire ce genre de choses atomique. » Ce que vous perdez est cette garantie que vous obtenez toujours quelque chose en retour. Si vous essayez de lire au milieu d'une écriture, vous pouvez récupérer les données d'ordures. Mais, d'autre part, vous allez un peu plus vite. 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. S'il est une propriété que vous accédez à beaucoup, vous voudrez peut-être descendre à nonatomic pour vous assurer que vous n'êtes pas encourir cette pénalité de vitesse.

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

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

Comment déclarer:

Comme atomique est donc défaut,

@property (retain) NSString *name;

ET 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 « le nom » du fil A ,

Et

En même temps, si vous appelez

[self setName:@"Datta"]

de fil B ,

Si maintenant * propriété de nom est nonatomic alors

• Il retourne la valeur « 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

• Elle veillera à la valeur « Sourov » A
• Ensuite, il retournera la valeur « Datta » B

Voilà pourquoi atomique est appelé thread - safe et c'est la raison pour laquelle 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 par fil de la variable (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-property-attributes-or.html

Si vous utilisez votre propriété dans le code multi-thread, vous serez alors 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.

Avant de commencer: Vous devez savoir que chaque objet en mémoire doit être désallouée de la mémoire pour une nouvelle écriture se produise. Vous ne pouvez pas tout simplement écrire sur le dessus de quelque chose que vous faites sur le papier. Vous devez d' abord effacer (dealloc) et vous pouvez écrire sur elle. Si au moment où l'effacement est fait (ou la moitié fait) et rien n'a 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.

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

atomic Ce 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 seulement écrit 4 des 8 lettres à ÉCRIT, ne peut lire au milieu, la lecture ne peut se faire lorsque les 8 lettres est écrit -> Pas de lecture (get) se produira 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 alors il lirait de la valeur d'un autoreleased objet.
• Si avant l' écriture que vous avez effacé ce qui a déjà été écrit sur papier, puis quelqu'un veut lire , vous pouvez toujours lire. Comment? Vous serez en train de lire quelque chose de similaire à bin Trash Mac OS (comme Poubelle n'est pas encore 100% effacé ... il est dans les limbes) ---> Si ThreadA est à lire en ThreadB a déjà dealloced à écrire, vous le feriez pourrait soit obtenir la valeur de la valeur entièrement écrite finale par ThreadB ou obtenir quelque chose de la piscine autorelease.

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

• Atomique ne garantit la sécurité des threads, bien que son utile pour la réalisation de 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.

Attends quoi?! Sont multithreading et la sécurité des threads différents?

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, parce qu'il ya un coût de performance et pour la plupart des choses vraiment pas besoin de sécurité de fil. Quelques parties de notre code ont besoin et pour les quelques pièces nous devons écrire notre code dans un fil de façon sûre à l'aide des serrures, mutex ou la synchronisation.

nonatomic

• Comme il n'y a pas une telle chose comme Mac OS Corbeille, personne ne se soucie si oui ou non vous obtenez toujours une valeur (<- Cela pourrait conduire à un accident), ni personne se soucie si quelqu'un essaie de lire à mi-chemin à travers vous écrire (bien que écrit à mi-chemin dans la mémoire 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 ne voyez la moitié de ce qui a été écrit) -> ne garantit pas de ne pas tomber en panne, parce que il n'utilise pas le mécanisme 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 autorelease piscine.

• 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 entièrement écrite.

Avant de discuter sur les attributs de @property, vous devez savoir ce qui est l'utilisation de @property. @property offre un moyen de définir les informations qu'une classe est destinée à encapsuler. Si vous déclarez un objet / variable en utilisant @property, alors que l'objet / variable sera accessible aux autres classes importateurs de sa catégorie. Si vous déclarez un objet en utilisant @property dans le fichier d'en-tête, alors vous devez en faire la synthèse en utilisant @synthesize dans le fichier de mise en œuvre.

Exemple:

classe .h

@interface ExampleClass : NSObject
   @property (nonatomic, retain) NSString *name;
@end

classe .m

@implementation ExampleClass
   @synthesize name;
@end

Maintenant, le compilateur fera la synthèse des méthodes pour le nom accesseur.

ExampleClass *newObject=[[ExampleClass alloc]init];
NSString *name1=[newObject name]; // get 'name'
[obj setName:@“Tiger”];

Liste des attributs de @property: atomique. nonatomic. conserver. copie. lecture seulement. lire écrire. attribuer. fort.

atomique: Il est le comportement par défaut. Si un objet est déclaré comme atomique il devient alors thread-safe. des moyens de thread-safe, à la fois un seul fil d'une instance particulière de cette classe peuvent avoir le contrôle sur cet objet.

Exemple :

@property NSString *name; //by default atomic
@property (atomic)NSString *name; // explicitly declared atomic

nonatomic: Il n'est pas thread-safe. Vous pouvez utiliser l'attribut de propriété nonatomic pour spécifier que accesseurs synthétisés 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. Pour cette raison, il est plus rapide d'accéder à une propriété nonatomic qu'un un atomique. @property (nonatomic)NSString *name;

retenir: est nécessaire lorsque l'attribut est un pointeur vers une méthode setter objet.Le va augmenter le nombre de conserver l'objet, de sorte qu'il occupera la mémoire dans la piscine autorelease. @property (retain)NSString *name;

copie: Si vous utilisez une copie, vous ne pouvez pas utiliser retenir. L'utilisation par exemple de copie de la classe contiendra sa propre copie. Même si une chaîne mutable est défini et modifié par la suite, l'instance capture quelle que soit la valeur qu'elle a au moment où elle est définie. Aucune méthode setter et getter seront synthétisés.

@property (copy) NSString *name;

NSMutableString *nameString = [NSMutableString stringWithString:@"Liza"];    
xyzObj.name = nameString;    
[nameString appendString:@"Pizza"];

readonly: Si vous ne souhaitez pas autoriser la propriété à modifier via la méthode setter, vous pouvez déclarer la propriété en lecture seule. @property (readonly) NSString *name;

readwrite: est le comportement par défaut. Vous n'avez pas besoin de spécifier explicitement attribut readwrite.

@property (readwrite) NSString *name;

assigner: va générer un setter qui affecte la valeur de la variable d'instance directement, plutôt que de copier ou de son maintien. Il est préférable pour les types primitifs comme NSInteger et CGFloat ou objets que vous ne possédez pas directement, comme les délégués.

@property (assign) NSInteger year;

forte: est un remplacement pour conserver. @property (nonatomic, strong) AVPlayer *player;

unsafe_unretained: Il y a quelques classes Cocoa et Cocoa Touch qui ne supportent pas encore des références faibles, ce qui signifie que vous ne pouvez pas déclarer une propriété faible ou faible variable locale de garder une trace d'eux. Ces classes comprennent NSTextView, NSFont et NSColorSpace, etc. Si vous avez besoin d'utiliser une faible référence à une de ces classes, vous devez utiliser une référence dangereuse. Une référence à risque est similaire à une référence faible en ce qu'elle ne tient pas son objet associé en vie, mais il ne sera pas mis à zéro si l'objet de destination est désaffectée.

@property (unsafe_unretained) NSObject *unsafeProperty;

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 accesseurs simplement synthétisé 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.

signifie un seul fil atomique 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.

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.

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, vous récupérerez une valeur valide. Il ne fait aucune garantie quant à ce que la valeur pourrait être, mais vous récupérerez de bonnes données, pas seulement la mémoire indésirable. Cela vous permet de faire est si vous avez plusieurs threads ou plusieurs processus pointant à une seule variable, un thread peut lire et un autre thread peut écrire. S'ils ont frappé en même 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 que atomique ne vous donne pas est une sorte de garantie dont ces valeurs que vous pourriez obtenir. Atomique est vraiment souvent confondu avec être thread-safe, et qui ne sont pas corrects. Vous devez garantir votre sécurité de 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 pas faire ce genre de choses atomique. » Ce que vous perdez est cette garantie que vous obtenez toujours quelque chose en retour. Si vous essayez de lire au milieu d'une écriture, vous pouvez récupérer les données d'ordures. Mais, d'autre part, vous allez un peu plus vite. 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. S'il est une propriété que vous accédez à beaucoup, vous voudrez peut-être descendre à nonatomic pour vous assurer que vous n'êtes pas encourir cette pénalité de vitesse. Accès

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

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.

Donc - si vous définissez une propriété atomique en Objective-C, il demeurera atomique lorsqu'il est utilisé par Swift.

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

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 bonne en perspective de performance, aura un comportement par défaut.

Non Propriétés 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 lorsque deux threads différents veulent variables accéder en même temps il donnera des résultats inattendus.

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);
    }

Pour simplifier la toute confusion laissez-nous comprendre verrou mutex lock.Mutex selon le nom verrouille la mutabilité du object.So si l'objet est accessible par une classe aucune autre classe peut accéder à la même object.In iOS @sychronise fournir aussi le mutex lock.Now il sert en mode FIFO et assure le flux est pas affectée par deux classes partageant la même instance.However si la tâche est la principale éviter de threads objet qui accède à l'aide des propriétés 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 frein filet.