FROM : Ben Lachman
DATE : Sun Mar 30 10:46:38 2008
On Mar 29, 2008, at 11:48 PM, Jeff LaMarche wrote:
> Are you using separate managed object contexts for each thread?
> According to the documentation here:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/
> Articles/cdMultiThreading.html
>
> That's the way to do it - pass managed object IDs between threads,
> not managed objects, and when you're done, you can call
> refreshObject:mergeChanges: on the main thread's context with the
> objects that were changed, then call processPendingChanges on it.
He stated that using the 1 MOC/thread scheme doesn't work for his
situation since in doing so you have to save: whenever you want to
sync the MOCs in different threads. I'm actually interested in this
question as I just rewrote a chunk of my app to do things the 1 MOC/
thread way and have seen pretty crappy performance due to all the
saving. My UI is slightly more responsive but particularly on older
(tiger) machines it really pegs the processor and disk with having to
save so much and the actually task takes significantly longer. The
other issue is that when you spawn a new thread/MOC you have to build
out any of the object graph that you'll need. In my case that is a
couple thousand objects and contributes to the performance hit as well.
So, the question still stands, is there a way to use CoreData driven
bindings in a multithreaded app with a single managed object
context? Anyone?
->Ben
--
Ben Lachman
Acacia Tree Software
http://acaciatreesoftware.com
<email_removed>
740.590.0009
>
> On Mar 29, 2008, at 11:30 PM, David wrote:
>
>> I would think this is the normal typical case, but can't figure it
>> out.
>> The UI should run on one thread, another thread should be used for
>> time
>> consuming updates/generation of an object tree maintained using
>> Core Data. I
>> have a NSOutlineView (via NSTreeController subclass) which
>> displays the
>> object tree from Core data.
>>
>> I can not figure out how to make this thread safe. I periodically
>> get random
>> data showing up in the outline view while the core data object
>> tree is being
>> updated.
>>
>> I've tried locking the managedObjectContext when I make additions
>> or changes
>> to the object tree, but I still get erroneous data showing up in
>> the view.
>>
>> I don't understand how NSTreeController and bindings are
>> interacting with
>> Core data to extract the data while I'm populating it.
>>
>> Any suggestions greatly appreciated.
>>
>> I've been reading and rereading the Core Data programming guide and
>> Threading programming guide to no avail.
>>
>> The Core data programming guide says its best to maintain a separate
>> managedObjectContext per thread. But this appears to require the
>> data to be
>> written to persistent store to make it work (file). That not
>> reasonable in
>> my case where I'm adding many objects to an object tree. It takes a
>> significant amount to time to write it out, negating the benefit
>> of trying
>> to make the UI seem responsive.
>>
>> I'm running Leopard.
>>
DATE : Sun Mar 30 10:46:38 2008
On Mar 29, 2008, at 11:48 PM, Jeff LaMarche wrote:
> Are you using separate managed object contexts for each thread?
> According to the documentation here:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/
> Articles/cdMultiThreading.html
>
> That's the way to do it - pass managed object IDs between threads,
> not managed objects, and when you're done, you can call
> refreshObject:mergeChanges: on the main thread's context with the
> objects that were changed, then call processPendingChanges on it.
He stated that using the 1 MOC/thread scheme doesn't work for his
situation since in doing so you have to save: whenever you want to
sync the MOCs in different threads. I'm actually interested in this
question as I just rewrote a chunk of my app to do things the 1 MOC/
thread way and have seen pretty crappy performance due to all the
saving. My UI is slightly more responsive but particularly on older
(tiger) machines it really pegs the processor and disk with having to
save so much and the actually task takes significantly longer. The
other issue is that when you spawn a new thread/MOC you have to build
out any of the object graph that you'll need. In my case that is a
couple thousand objects and contributes to the performance hit as well.
So, the question still stands, is there a way to use CoreData driven
bindings in a multithreaded app with a single managed object
context? Anyone?
->Ben
--
Ben Lachman
Acacia Tree Software
http://acaciatreesoftware.com
<email_removed>
740.590.0009
>
> On Mar 29, 2008, at 11:30 PM, David wrote:
>
>> I would think this is the normal typical case, but can't figure it
>> out.
>> The UI should run on one thread, another thread should be used for
>> time
>> consuming updates/generation of an object tree maintained using
>> Core Data. I
>> have a NSOutlineView (via NSTreeController subclass) which
>> displays the
>> object tree from Core data.
>>
>> I can not figure out how to make this thread safe. I periodically
>> get random
>> data showing up in the outline view while the core data object
>> tree is being
>> updated.
>>
>> I've tried locking the managedObjectContext when I make additions
>> or changes
>> to the object tree, but I still get erroneous data showing up in
>> the view.
>>
>> I don't understand how NSTreeController and bindings are
>> interacting with
>> Core data to extract the data while I'm populating it.
>>
>> Any suggestions greatly appreciated.
>>
>> I've been reading and rereading the Core Data programming guide and
>> Threading programming guide to no avail.
>>
>> The Core data programming guide says its best to maintain a separate
>> managedObjectContext per thread. But this appears to require the
>> data to be
>> written to persistent store to make it work (file). That not
>> reasonable in
>> my case where I'm adding many objects to an object tree. It takes a
>> significant amount to time to write it out, negating the benefit
>> of trying
>> to make the UI seem responsive.
>>
>> I'm running Leopard.
>>






Cocoa mail archive

