Specifications sur atomic/nonatomic
Bonjour à tous.
Il y a quelque chose qui me chiffonne énormément lorsque l'on développe à la fois sur Mac et sur iOS.
Sur Mac, les property sont par défaut atomics (je dis par défaut, car c'est comme ça qu'Xcode génère le APp Delegate par exemple).
Pour un projet iOS, Xcode génère des property nonatomic.
J'ai bien compris la différence entre les deux, seulement j'ai du mal à comprendre pourquoi utiliser des property atomics sur Mac, et nonatomic sur iOS.
Concrètement, pour une property atomic, Apple spécifie que les getters/setters générés par @synthesize contiennent un lock (@synchronized). Et que donc, les properties nonatomics sont donc plus rapide puisqu'elles ne garanties pas ce fameux lock, mais sont donc plus risquées dans un environnement multi-thread.
La question peut paraà®tre idiote, mais si je comprend bien, du fait que sur un ordinateur nous avons plusieurs core, les property atomic sont recommandées? Pour moi c'est complètement faux, étant donné qu'un seul thread accèdera à la plupart des getters/setters. Et si il y a besoin de gérer un objet pour une utilisation par plusieurs thread, j'ai toujours pris soin d'ajouter @synchronized.
À l'inverse, sur iOS, du fait de la moindre puissance des processeurs, l'utilisation de nonatomic est recommandée car plus rapide?
Mais est-il possible pour moi d'écrire, sur iOS dans le cas où je ré-implémente le getter/setter pour une property nonatomic, ET dans le cas de l'accès via plusieurs threads:
Ou vaut-il mieux utiliser directement une property atomic dans ce cas là .. (ce qui m'évite de réécrire le setter/getter en fait dans certains cas)
Je n'ai pas su trouver de doc explicite chez Apple comparant le cas OS X / iOS..
Si les grands gourous pouvaient m'éclairer :P
Il y a quelque chose qui me chiffonne énormément lorsque l'on développe à la fois sur Mac et sur iOS.
Sur Mac, les property sont par défaut atomics (je dis par défaut, car c'est comme ça qu'Xcode génère le APp Delegate par exemple).
Pour un projet iOS, Xcode génère des property nonatomic.
J'ai bien compris la différence entre les deux, seulement j'ai du mal à comprendre pourquoi utiliser des property atomics sur Mac, et nonatomic sur iOS.
Concrètement, pour une property atomic, Apple spécifie que les getters/setters générés par @synthesize contiennent un lock (@synchronized). Et que donc, les properties nonatomics sont donc plus rapide puisqu'elles ne garanties pas ce fameux lock, mais sont donc plus risquées dans un environnement multi-thread.
La question peut paraà®tre idiote, mais si je comprend bien, du fait que sur un ordinateur nous avons plusieurs core, les property atomic sont recommandées? Pour moi c'est complètement faux, étant donné qu'un seul thread accèdera à la plupart des getters/setters. Et si il y a besoin de gérer un objet pour une utilisation par plusieurs thread, j'ai toujours pris soin d'ajouter @synchronized.
À l'inverse, sur iOS, du fait de la moindre puissance des processeurs, l'utilisation de nonatomic est recommandée car plus rapide?
Mais est-il possible pour moi d'écrire, sur iOS dans le cas où je ré-implémente le getter/setter pour une property nonatomic, ET dans le cas de l'accès via plusieurs threads:
<br />@property (nonatomic, retain) id foo;<br /><br />- (void)setFoo:(id)aFood<br />{<br /> @synchronized(self){<br /> .....<br /> }<br />}<br />
Ou vaut-il mieux utiliser directement une property atomic dans ce cas là .. (ce qui m'évite de réécrire le setter/getter en fait dans certains cas)
Je n'ai pas su trouver de doc explicite chez Apple comparant le cas OS X / iOS..
Si les grands gourous pouvaient m'éclairer :P
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
la question est mal posée
Demande toi plutôt "Puis je enlever la synchronisation?". Si après maintes reflexions tu penses que c'est possible, teste et re-teste encore.
le multithreading est loin tres trivial.
J'arrive à cerner la différence entre atomic et nonatomic, c'est juste que je déteste mal faire les choses et ne pas suivre ce que préconise Apple. En l'occurrence je ne trouve plus la doc qui stipulait qu'il fallait privilégier l'atomic sur OS X et le nonatomic sur iOS.
Pour moi, une property nonatomic dont le getter/setter est réécrit et inclus un @synchronized équivaut à une property atomic, et dans ce cas l'info "nonatomic" renseignée n'est juste que purement descriptif...
oui, cette préconisation semble idiote.
il est parfaitement possible de faire du monothread sur un multicore, ou du multithread sur un monocore,
OS X ou iOS.
ceci dit par defaut l'atomic devrait etre "activé". Au programmeur de savoir ce qu'il fait.
Autant sur iOS c'est tout à fait compréhensible.. nonatomic sera plus rapide (on parle de picosecondes...) sur iOS.. mais sur OS X honnêtement j'ai du mal à voir pourquoi utiliser l'atomic par défaut.. Je veux dire, si je suis sûr que certaines variables ne seront qu'accessible via le main thread, aucun intérêt pour moi d'utiliser de l'atomic.
Donc qu'il mette atomic ou nonatomic par défaut, de toute façon selon les cas faudra p'tet que tu changes, que ce soit sur OSX si tu fais du monothread et veux gagner des picosecondes en te disant que le lock n'est pas nécessaire, ou sur iPhone si tu fais du multithread et que tu te dis qu'il faut rajouter un lock.
Je ne sais plus trop pourquoi Apple met l'un par défaut d'un côté, l'autre par défaut de l'autre, d'autant que ça les oblige à avoir la macro dont j'ai oublié le nom (NONATOMIC_IPHONE_ONLY un truc comme ça ?) pour gérer les 2 cas dans leurs headers communs iOS/OSX. Sans doute parce que sous OSX, les proc sont si puissants, que mettre un lock ne gène pas trop les perfs... d'autant que GCD existe depuis pas mal de temps sous OSX, quelques APIs sont basées dessus au niveau multi-thread, et que les locks qu'utilise GCD sont en 2 temps, d'abord un lock rapide dans le user-space avant de passer au lock au niveau plus bas si vraiment y'a besoin, ce qui fait gagner en perfs également. Et du coup mettre tout en atomic, c'est pas vraiment gênant, donc autant le mettre.
Alors que sous iOS historiquement y'a un proc moins puissant et pas de GCD (même si depuis les choses ont évolué) et qu'un lock est plus coûteux, donc tu peux mettre des propriété atomic si tu veux, mais faut mieux les mettre atomic que si c'est vraiment nécessaire.
Mais tout ceci n'est qu'une supposition.