Accès aux attributs d'instance à partir du thread secondaire (iPhone-SDK)

Question

J'ai une classe avec un attribut NSDictionary. A l'intérieur de cette classe, je distribue un autre thread pour gérer la gestion de NSXMLParser. Dans mon -didStartElement, j'accède au dictionnaire de la classe (pour comparer un élément trouvé dans le XML à un dans le dictionnaire).

À ce stade, j'obtiens des résultats indéfinis. En utilisant NSLog (je ne suis pas avancé dans le débogage XCode), je vois qu'il bombarde autour de l'accès du NSDictionary. J'ai essayé juste d'itérer le dictionnaire et de jeter la clé/les valeurs dans le didStartElement et cette bombe à des clés différentes à chaque fois. La seule chose que je peux conclure est que quelque chose n'est pas casher que je fais en ce qui concerne l'accès aux attributs de threads principaux du thread secondaire. Je suis un peu novice dans le domaine du multithreading et je ne suis pas sûr du meilleur accès au protocole à partir des threads supplémentaires.

Merci à tous.

Answer 1

Je serais surpris si vous pouviez accéder à la mémoire utilisée par un thread dans un autre thread sauf si ce dictionnaire est statique/global. Je prendrais une des deux approches, ne connaissant pas les subtilités de l'iPhone SDK -

1. Poignée tous les accès au dictionnaire dans le thread séparé (population, instanciation, etc.), les recherches
2. utiliser une sorte de L'équivalent d'un dictionnaire multithread pour iPhone: link

Answer 2

Il existe peu de moyens d'activer l'accès thread-safe aux variables instances dans Objective-C. Le plus simple est de définir votre déclaration @property comme atomique. Dans ce cas, les setters et accesseurs générés automatiquement seraient synchronisés sur self. L'autre manière consiste à envelopper votre code critique dans un bloc @ synchronisé. La manière la plus préférable serait de créer une sous-classe NSOperation qui gère la récupération et l'analyse, et fournit des rappels par délégation ou des blocs (si vous êtes> = iOS4.0), pour informer votre consommateur que l'opération a été achevée .

NSOperations simultanées ont besoin d'un peu de code passe-partout afin de les faire fonctionner correctement, voir cela (l'exemple est pour Snow Leopard, mais le concept est le même): http://www.dribin.org/dave/blog/archives/2009/05/05/concurrent_operations/