On Nov 21, 2010, at 11:47 AM, vincent habchi <vi...@macports.org> wrote:
> briefly speaking, I have a Core Data Entity bearing a to-many relationship > (therefore an NSSet * iVar). A dialog on the main thread can modify this set, > while it may be simultaneously enumerated on a background GCD thread. I have > therefore used the managed object context provided mutex to protect the > respective snippets. Don't do this. If you're using bindings or KVO at all in your main thread, you CANNOT lock your context every place you need to in order to make this safe. Furthermore, I suspect you may not be locking your context on the background thread because you're "just reading" - that's also incorrect. Use a separate context on the background thread, attached to the same NSPersistentStoreCoordinator, and only pass managed object IDs between threads. Also, be sure to create your background thread's context on the thread or queue which you wish to use it; don't create one on the main thread and then pass it in to your background thread. (The reason for is is that a context can care about eg the run loop it's on. You don't want to use a context attached to the main thread's run loop from a background thread.) This is pretty much the standard for Core Data multithreading: thread isolation of object graphs (as represented by contexts), passing only object IDs( and did-save notifications containing object IDs) between threads. -- Chris _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
