Re: Cocoa binding and threads.
Re: Cocoa binding and threads.
- Subject: Re: Cocoa binding and threads.
- From: Chris Hanson <email@hidden>
- Date: Wed, 16 Aug 2006 13:06:42 -0700
On Aug 16, 2006, at 6:48 AM, David Burnett wrote:
Are you saying that just *reading* values from different objects in
a single context in different threads is not supported. That is a
bit of blow IMHO, especially when multi-core CPU's are going to
lead to a more
threaded software architecture.
Core Data does support the development of multi-threaded
applications. Doing so just requires that you follow the multi-
threading strategy established by the framework.
Any interaction with a managed object -- reading or writing --
results in interaction with its managed object context. To interact
with a managed object context, you must either (a) guarantee that it
will only ever be interacted with on a single thread or (b) perform
the appropriate locking (via the locking mechanism provided by
NSManagedObjectContext) to ensure that only one thread at a time is
interacting with it.
This will cause all of the appropriate locking to take place further
down the persistence stack, for example on any caches that Core Data
maintains on behalf of persistent stores. As should be obvious, both
reading and writing can easily cause this kind of state to change,
resulting in an inconsistency if the changes aren't properly
synchronized.
Back to the main topic, I do have code that attempts to read values
from a different managed object, the currently selected but as far
as I'm aware the new object is created
(insertNewObjectForEntityForName...) and all values are set /
altered in functions that are called using
performSelectorOnMainThread. Calling processPendingChanges using
performSelectorOnMainThread appears to solve the issue, still
leaving the question as to why the changes where pending.
It may appear to solve the issue, but if you're reading values from a
managed object whose context is in use in more than one thread at
once without locking, your code still isn't correct. You'll really
need to adjust your code's architecture to avoid working with a
context that's used by your views and controllers in a non-main thread.
One correction to what I said earlier: I said that KVO isn't thread-
safe. It actually is; however, it's thread-safe in the same sense
that NSNotificationCenter is: Just like an NSNotification, key-value
observing notifications are delivered synchronously when they're
posted, and thus are delivered on the thread in which they're posted.
So KVO notifications are not "cross-thread-safe" -- meaning that a
change to an observed object made on one thread will not cause the
observer to be notified on the main thread. Bindings are layered
atop KVO, which is why you can't just change an object that's bound
to in a separate thread and expect the views and controllers bound to
it to cope.
-- 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