iphone - Uso multiproceso de datos básicos(NSOperationQueue y NSManagedObjectContext)
objective-c multithreading (3)
En la documentación de datos básicos de Apple para simultaneidad con datos centrales , enumeran el método preferido para la seguridad de subprocesos como el uso de un NSManagedObjectContext separado por subproceso, con un NSPersistentStoreCoordinator compartido.
Si tengo varias NSOperations ejecutándose una tras otra en un NSOperationQueue, ¿habrá una gran sobrecarga que cree el contexto con cada tarea?
Con NSOperationQueue teniendo un recuento máximo de operación simultánea de 1, muchas de mis operaciones utilizarán el mismo subproceso. ¿Puedo usar el diccionario de subprocesos para crear un NSManagedObjectContext por subproceso? Si lo hago, ¿tendré problemas para limpiar mis contextos más tarde?
¿Cuál es la forma correcta de usar Core Data en esta instancia?
Las operaciones que comenzaron a usar NSOperationQueue utilizando una cuenta de operación simultánea máxima de 1 no ejecutarán todas las operaciones en el mismo subproceso. Las operaciones se ejecutarán una después de la otra, pero se creará un nuevo hilo cada vez.
Entonces, la creación de objetos en el diccionario de hilo será de poca utilidad.
La forma correcta de utilizar Core Data en este caso es crear un NSManagedObjectContext por operación o tener un único contexto que bloquee (mediante -[NSManagedObjectContext lock] antes de su uso y -[NSManagedObjectContext unlock] después de su uso). El enfoque bloqueado puede tener sentido si las operaciones son en serie y no hay otros subprocesos usando el contexto.
Qué enfoque usar es una pregunta empírica que no puede ser evaluada sin datos. Hay demasiadas variables para tener una regla general. Los números duros de las pruebas de rendimiento son la única forma de tomar una decisión informada.
Si bien esta pregunta es antigua, en realidad está en la parte superior de los resultados de búsqueda de Google en ''NSMangedObjectContext threading'', así que solo daré una nueva respuesta.
El nuevo método ''preferido'' es usar initWithConcurrencyType: y decirle al MOC si es un hilo principal MOC o un hilo secundario moc. Luego puede usar los nuevos métodos performBlock: y performBlockAndWait: y el MOC se encargará de las operaciones de serialización en su hilo ''nativo''.
El problema entonces es cómo manejar inteligentemente la fusión de los datos entre los diversos MOC que su aplicación puede engendrar, junto con otros mil detalles que hacen que la vida sea ''divertida'' como programador.