Re: Core Data and multithreading (was Re: [Core Data] Improve save performance ?)
Re: Core Data and multithreading (was Re: [Core Data] Improve save performance ?)
- Subject: Re: Core Data and multithreading (was Re: [Core Data] Improve save performance ?)
- From: Eric Morand <email@hidden>
- Date: Tue, 17 Jan 2006 21:37:38 +0100
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.
I obviously lock the context before saving in my detached thread (and
unock after). :o)
What I (and others) wonder is : should I lock BEFORE detaching the
thread and can I lock in the detached thread ?
Le 17 janv. 06 à 19:56, Chris Hanson a écrit :
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
=============================================
Automator Ketchup : http://automatorketchup.blogspot.com
_______________________________________________
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