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, I'm still having a hard time grasping how each concurrency type is used. Below is how I'm interpreting each type. Please correct me if I'm understanding anything incorrectly.

NSConfinementConcurrencyType

This type has been the norm over the last few years. MOC's are shielded from each thread. So if thread A MOC wants to merge data from Thread B MOC via a save message, thread A would need to subscribe to thread B's MOC save notification.

NSPrivateQueueConcurrencyType

Each MOC tree (parent & children MOCs) share the same queue no matter what thread each is on. So whenever a save message from any of these contexts is sent, it is put in a private cue specifically made only for this MOC tree.

NSMainQueueConcurrencyType

Still confused by this one. From what I gather it's the like NSPrivateQueueConcurrencyType, only the private queue is run on the main thread. I read that this is beneficial for UI communications with the MOC, but why? Why would I choose this over NSPrivateQueueConcurrencyType? I'm assuming that since the NSMainQueueConcurrencyType is executed in the main thread, does this not allow for background processes? Isn't this the same as not using threads?

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.