Menu
Is initializing a NSManagedObjectContext using NSMainQueueConcurrencyType only for the situation where that MOC has a child MOC that was initialized using NSPrivateQueueConcurrencyType?
To give some background: my app has a traditional structure whereby the main table view is driven by a NSFetchedResultsController and data are imported asynchronously from a web service using an NSOperation subclass that has its own MOC. I wasn't sure whether both MOCs in that situation should use NSConfinementConcurrencyType (the default, I believe) or whether the MOC associated with the fetched results controller on the main thread should use NSMainQueueConcurrencyType and the background MOC should use NSConfinementConcurrencyType.
779
Core Data is designed to work in a multithreaded environment. However, not every object under the Core Data framework is thread safe. To use Core Data in a multithreaded environment, ensure that: Managed object contexts are bound to the thread (queue) that they are associated with upon initialization.
Concurrency is the ability to work with the data on more than one queue at the same time. If you choose to use concurrency with Core Data, you also need to consider the application environment. For the most part, AppKit and UIKit are not thread-safe.
functions are thread safe and can be called from other threads. A NSManagedObject cannot be shared across threads. A NSManagedObjectID can be shared across threads. Changes from one NSManagedObjectContext can be merged into another NSManagedObjectContext , even on another thread.
Managed Object ContextThe NSManagedObjectContext class isn't thread safe. Plain and simple. You should never share managed object contexts between threads. This is a hard rule you shouldn't break.
First a recipe on Core Data new context types.
NSMainQueueConcurrencyType creates a context that is associated with the main dispatch queue and thus the main thread. You could use such a context to link it to objects that are required to run on the main thread, for example UI elements.
NSPrivateQueueConcurrencyType creates and manages a private dispatch queue to operate on. You must use the new methods performBlock: or performBlockAndWait:. The context will then execute the passed blocks on its own private queue.
Finally, NSConfinementConcurrencyType is the default type and can be used only within the thread where it has been created. So, within your NSOperation, you have used it in the right manner. A simple note. If you want to use it as a child context, you need to have a "queue context" (NSMainQueueConcurrencyType or NSPrivateQueueConcurrencyType).
Now, about your question.
Is initializing a NSManagedObjectContext using NSMainQueueConcurrencyType only for the situation where that MOC has a child MOC that was initialized using NSPrivateQueueConcurrencyType?
No, not necessary. Yes, you could set up a private context that does some work in background and then pushes the retrieved objects to the main one, but I will do the contrary: use a NSPrivateQueueConcurrencyType as the master context and the NSMainQueueConcurrencyType as a child context for the former. In this way, the main context will deal only with objects that are in memory. Save to disk are performed by the private queue only.
This approach is used by the UIManagedDocument class. Save to disk are performed in a background thread (a private queue). In this manner the UI is not freezed.
55
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
