I have an iPhone application I am developing which transfers data over the network and saves the data received in core data object for use later on. Presently. it works correctly in a single thread but I am working on converting the data transfer mechanism to run in a separate worker thread.
I've read the core data programming guide on multithreading and I'm planning on using separate managed object contexts for each thread and a single persistent store coordinator as seems to be recommended by Apple.
The application's main thread will never need to create or delete core data objects and will instead ask the worker thread. It will mostly be reading the objects and occasionally modifying them. It will also periodically ask the worker thread to fetch new objects or updates for existing objects from the network.
My question involves what I need to do to support this. The multithreading section of the core data programming says that I can "pass" objects between the two threads by passing object IDs. I'm a little confused as to exactly what I need to do. Do the two threads each have their own copy of each object the have fetched? If so, how are they synced? Are you supposed to explicitly fault objects you know the other thread has modified to get them to reload?
Let's say I am using an object in the main thread, and the worker thread modifies it. Is it enough to have the worker thread inform the main thread that the object was modified so the main thread can fault it forcing a reload? Or will it be faulted automatically? Or maybe this whole scenario is a bad idea and would cause an execption?
I'm thinking of implementing this by having a dictionary in the main thread of all the objects that are presently being used. When the worker thread modifies one, presumably because it fetched an updated version from the network, I am going to have it signal the main thread and the main thread can fault the object if it is currently on its list of objects it is using. Does this sound like a good idea, or is it even necessary?