Est-ce que les autres threads peuvent avoir un accès indirect à un contexte d'objet géré s'exécutant dans un thread propre?

Question

La méthode recommandée par Apple pour le multithreading de données de base consiste à utiliser un contexte d'objet géré par thread et à envoyer les modifications d'un contexte à un autre en enregistrant le contexte du thread modifié dans un stockage persistant partagé.

Bien que je puisse imaginer que cela soit bien pour, par exemple. un lecteur RSS, pour certaines applications, il semble loin d'être idéal. Dans mon cas, j'écris un séquenceur de musique qui enregistre des données & en utilisant un fil de fond. J'ai besoin que les données enregistrées soient accessibles au thread principal pendant l'enregistrement/la lecture. Avoir à constamment enregistrer et charger des données tout en enregistrant/en jouant serait assez mauvais, mais pire, il semblerait forcer l'utilisateur à enregistrer chaque fois qu'ils enregistrent ou jouent, ce qui crie un peu «terrible application».

Cependant, il semble qu'il pourrait y avoir un moyen de contourner ce problème. Si d'autres threads n'ont pas besoin d'accéder aux entités de données principales (uniquement les données qu'ils contiennent), qu'est ce qui m'empêche d'exécuter le contexte d'objet géré dans son propre thread et de n'autoriser que l'accès indirect aux autres threads? Objets à une propriété qui appelle performSelector:onThread:withObject:waitUntilDone: sur le thread du contexte d'objet géré pour obtenir/définir des valeurs? Cela ne donne pas certains des avantages du multithreading (c'est-à-dire la mise à l'échelle des données de base vers les processeurs multicœurs), mais la plupart du temps, nous voulons que le multithreading évite de verrouiller l'interface utilisateur.

Je n'ai pas vu ce modèle préconisé pour les données de base. Étant donné que cela peut être une bête étrange et imprévisible quand vous ne faites pas exactement ce que Apple suggère, j'ai pensé qu'il serait utile de demander si cela évite vraiment les raisons pour lesquelles nous sommes découragés de laisser plusieurs threads accéder à un seul contexte d'objet géré .

Answer 1

Vous n'avez aucun contrôle sur les détails d'implémentation des composants internes de NSManagedObject et, plus précisément, il existe des raisons pour lesquelles CoreData peut avoir besoin de faire quelque chose dans le contexte lorsque vous lisez un attribut. Pour vos besoins particuliers, je suggère une solution isolée, tampon et de file d'attente hautement optimisée, où vous copiez ce qui est nécessaire sur les objets CD avant de les passer à un thread de traitement en arrière-plan.

---

Vous pouvez utiliser performSelector sur * Discussion: si vous voulez, mais vous serez face à des problèmes de synchronisation, la latence et autres bits amusants de concurrency. Personnellement, j'irais avec le mécanisme de file d'attente décrit ci-dessus.