I'm working on a project that uses CoreData objects on multiple
threads at once, where it's not uncommon for the main thread to be
loading data at the same time that an NSOperation running in the
background is processing a different set of data.
Whenever I fetch or store data from an NSManagedObjectContext, I
always make sure to lock and unlock it using the provided methods.
Why aren't you using a separate MOC for the main thread and the
NSOperation ? If you are, then you don't need to lock MOCs that are
perfectly isolated. If you are not, then you'll still need to lock
the MOC when working with the managed objects themselves (like
valueForKey) in addition to fetching or saving. As Miguel notes, we
discourage that usage pattern because it's (a) hard to get right and
(b) tediously locks constantly obviating most performance benefits
You have tried using the multi-threading assertions ? If you have
failed to lock a MOC or MO when we require you to, the multit-
threading assertions should detect that for you. ADC just released
the debug libraries for 10.5.6
How do I figure out who is locking the persistent store coordinator
and not unlocking it properly? It's a real mystery, since I've audited
my code several times now, and all locks appear to be balanced (and
until very recently, I wasn't even locking the persistent store
coordinator at all). I already tried setting breakpoints on -[_PFLock
lock] and -[_PFLock unlock] that print the stack traces, but it's
taking hours due to all of the locking and unlocking going on.
What does gdb say after the deadlock happens with:
> info threads
> thread apply all bt
- Ben
_______________________________________________
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
