iOS5 NSManagedObjectContext Concurrency types and how are they used?

Question

Literature seems a bit sparse at the moment about the new NSManagedObjectContext concurrency types. Aside from the WWDC 2011 vids and some other info I picked up along the way,

Answer 1

The queue concurrency types help you to manage mutlithreaded core data:

For both types, the actions only happen on the correct queue when you do them using one of the performBlock methods. i.e.

[context performBlock:^{
    dataObject.title = @"Title";
    [context save:nil]; // Do actual error handling here
}];

The private queue concurrency type does all it's work in a background thread. Great for processing or disk io.

The main queue type just does all it's actions on a UIThread. That's neccesary for when you need to do things like bind a NSFetchedResultsController up to it, or any other ui related tasks that need to be interwoven with processing that context's objects.

The real fun comes when you combine them. Imagine having a parent context that does all io on a background thread that is a private queue context, and then you do all your ui work against a child context of the main queue type. Thats essentially what UIManagedDocument does. It lets you keep you UI queue free from the busywork that has to be done to manage data.

Answer 2

midas06 wrote:

Imagine having a parent context that does all io on a background thread that is a private queue context, and then you do all your ui work against a child context of the main queue type.

I understood it to be the other way around: you put the parent context on the main thread using NSMainQueueConcurrencyType and the child context on the background thread using NSPrivateQueyeConcurrencyType. Am I wrong?

Answer 3

I think the answers are in the note : Core Data Release Notes for Mac OS X Lion http://developer.apple.com/library/mac/#releasenotes/DataManagement/RN-CoreData/_index.html

For NSPrivateQueueConcurrencyType, I think you are not right. A child context created with this concurrency type will have its own queue. The parent/child context is not entirely related to threading. The parent/child seems to simplify communication between contexts. I understand that you just have to save changes in the child contexts to bring them back in the parent context (I have not tested it yet). Usually parent/child context pattern are related to main queue/background queue pattern but it is not mandatory. [EDIT] It seems that access to the store (Save and Load) are done via the main context (in the main queue). So it is not a good solution to perform background fetches as the query behind executeFetchRequest will always be performed in the main queue.

For NSMainQueueConcurrencyType, it is the same as NSPrivateQueueConcurrencyType, but as it is related to main queue, I understand that you perform operation with the context without necesseraly using performBlock ; if you are in the context of the main queue, in View controller delegate code for example (viewDidLoad, etc).