Core Data and multithreading (was Re: [Core Data] Improve save performance ?)
Core Data and multithreading (was Re: [Core Data] Improve save performance ?)
- Subject: Core Data and multithreading (was Re: [Core Data] Improve save performance ?)
- From: Chris Hanson <email@hidden>
- Date: Tue, 17 Jan 2006 10:56:47 -0800
On Jan 17, 2006, at 9:04 AM, Eric Morand wrote:
Actually I was just about to ask about that. I have never done
that, but I assume that it shouldn't be that hard.
Pretty easy actually.
I've detached the save call to another thread and, well, it works
perfectly and now when the user click on the "submit" button, there
is no pause for him since the save is done in the "background" thread.
There appear to be some extremely common misconceptions about Core
Data and multithreading. My apologies in advance if you're doing
everything correctly, but from your statement "I've detached the save
call to another thread" I suspect you may run into some issues.
When working with Core Data, you MUST NOT interact with a managed
object context from multiple threads without appropriately locking
it. This is a requirement. There is no way to get around it. There
are no situations where it is unnecessary. Any situation you find
where it may appear unnecessary or where it seems to be working is a
bug waiting to manifest.
In Core Data, any interaction with a managed object can result in
indirect interaction with a managed object context. This means both
setting values and reading values. If you want to do this from
multiple threads, you MUST lock the object's context appropriately
around interactions.
Any bindings to objects can read from or change them. Bindings also
don't lock the managed object context of the objects they're
interacting with around that interaction. Since you can't add the
appropriate locking to bindings yourself, you MUST NOT interact with
a context that has bound objects from anything but the main thread.
-- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden