Re: NSPersistentStoreCoordinator Wars Episode I: The Phantom Lock Menace
Re: NSPersistentStoreCoordinator Wars Episode I: The Phantom Lock Menace
- Subject: Re: NSPersistentStoreCoordinator Wars Episode I: The Phantom Lock Menace
- From: sanchezm <email@hidden>
- Date: Thu, 8 Jan 2009 22:12:12 -0800
Nick,
I can't be sure on what thread access pattern you are following in
your application, but it sounds like you might be trying to access the
same object and managed object context instances from different
threads. This is tough to get right.
The preferred way of doing this is to have a separate context per
thread pass object IDs between threads
http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CoreData/Articles/cdMultiThreading.html#/
/apple_ref/doc/uid/TP40003385-SW2
In the above document you will also see the statement "If you lock
(or successfully tryLock) a context, that context must be retained
until you invoke unlock. If you don’t properly retain a context in a
multi-threaded environment, you may cause a deadlock."
Another thing you could try if have captured the deadlock in gdb is
to try to determine which of the other active threads hasn't released
the lock yet. You might do this by keeping a per thread counter that
you increment when you lock and decrement when you unlock. When the
deadlock is caught in gdb, you can inspect the other threads to see
which one has the counter in a locked state.
Finally, if you want to load data in a background thread you might
want to take a look at the example
/Developer/Examples/CoreData/BackgroundFetching
I hope all this gives you some hints,
- Miguel
On Jan 8, 2009, at 6:14 PM, Nick Zitzmann wrote:
Yes, I did try searching and found nothing interesting...
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.
But I'm having a problem where, if there are a lot of records in the
model ("a lot" defined as 1,000+), some phantom object is leaving a
stray lock open on the NSPersistentStoreCoordinator object, so I get
a deadlock as one thread is waiting for the NSManagedObjectContext
to unlock while the thread that has the lock is twiddling its thumbs
waiting forever for the NSManagedObjectContext to come unlocked. And
it's happening on all four CPU architectures.
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.
All I need is to get a stack trace to the code that locked the
context but forgot to unlock it, which I'd normally do by
subclassing the lock object and have the subclass keep track of
stack traces, but I can't hack CoreData to do this (and yes, I did
try posing, but it was too glitchy, and won't work on PPC64 or
X86-64 anyway).
I've also tried Guard Malloc, which can often catch glitchy
behavior, but so far it hasn't found anything either.
Or am I using the wrong locks in the first place?
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
email@hidden
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden