Lorsqu'Apple a introduit pour la première fois le concept de propriétés, la question de savoir si les propriétés pouvaient être utilisées à des fins commerciales a été largement débattue. atomic o nonatomic devrait être la règle par défaut et les atomistes ont gagné.
Je pense que le raisonnement est le suivant : dans un environnement threadé, à moins que la propriété ne soit atomique, vous ne pouvez pas garantir que le pointeur qu'elle renvoie est valide. Un getter non atomique serait implémenté de la manière suivante
-(MyObj*) someProperty
{
return someInstVar;
}
Il est possible qu'un autre thread désalloue l'objet pointé par someInstVar après que le pointeur a été placé dans le registre de retour mais avant que l'appelant n'ait eu le temps de le conserver. Même cela n'est pas bon :
-(MyObj*) someProperty
{
return [[someInstVar retain] autorelease];
}
parce qu'un autre thread pourrait désallouer un certainInstVar juste avant que le compte de conservation ne soit incrémenté.
La seule façon de renvoyer le pointeur en toute sécurité dans un environnement multithread est de procéder de la manière suivante :
-(MyObj*) someProperty
{
@synchronized(self)
{
return [[someInstVar retain] autorelease];
}
}
et de synchroniser également l'appareil de réglage.
Cependant, le problème est que le verrou est très coûteux (en réalité, ils ont utilisé quelque chose de beaucoup plus léger que @synchronized, mais c'est toujours coûteux), de sorte que tout le monde utilisait de toute façon des verrous non atomiques et le fait de rendre toutes les propriétés atomiques ne confère pas la sécurité des threads en général, de sorte que d'autres techniques sont nécessaires de toute façon et qu'elles tendent à éviter le problème dont j'ai parlé plus haut.
De nombreuses personnes pensent que la décision prise quant à la valeur par défaut n'est pas la bonne, mais elle ne peut pas être modifiée pour des raisons de rétrocompatibilité. Je me retrouve à taper nonatomic sans même y penser.
