• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Coredata and threads
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coredata and threads


  • Subject: Re: Coredata and threads
  • From: Todd Freese <email@hidden>
  • Date: Wed, 4 Jan 2006 15:52:17 -0600

Actually, I have a background thread that is importing objects. It creates the objects and needs to add them to the store. The main thread is displaying them. At no time do both threads access the store. Just the main thread.

In this case, I am thinking I should be OK. The importer thread would create a new context, add the obects, and call the main thread to update.

Or am I missing something major here?

Todd


On Jan 4, 2006, at 3:17 PM, Bill Bumgarner wrote:

On Jan 3, 2006, at 6:38 PM, Jeff LaMarche wrote:
I haven't been able to find much information on the "thread- safeness" of Core Data, but I'll tell you what I think based on my experiences, but with a disclaimer that some of this is probably wrong. I'm still fumbling around in the dark on one threaded Core Data application I'm working on and it ain't pretty ;-)

Guessing about thread behavior of an API is a sure fire way to guarantee job security or, if working for yourself, really long hours of debugging unbelievably painful data loss bugs that only occur in production on a model of machine you don't have access to.


You should only access a managed object (and the related context) from a single thread. If you need to access an object from different threads, then pass the global id from one thread to the other and realize the object in the other thread's managed object context. Do not assume that any operation is thread safe! In particular, a "read" operation may very likely cause the object graph to change in that it can easily trigger faulting. **Read operations are not thread safe**.

By and large, the AppKit is not thread safe. So, if you are using Core Data with Cocoa Bindings and, thus, have a managed object context bound to a controller, then that entire managed object context and all objects realized through it should ***only be used by the application's main thread***.

The managed object context and persistent store coordinator implements the NSLocking protocol such that you can appropriately cluster operations, as necessary.

So:
- one thread per managed object and managed object context
- many managed object contexts per thread, if needed
- pass global IDs between threads to access a managed object in a different thread


Now, with that said, you can actually use a managed object context from multiple threads, but only if you correctly lock/unlock the managed object context via the provided NSLocking methods around every use. Don't screw up or you will be in a world of hurt.

b.bum



_______________________________________________ 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
  • Follow-Ups:
    • Re: Coredata and threads
      • From: Bill Bumgarner <email@hidden>
References: 
 >Coredata and threads (From: Todd Freese <email@hidden>)
 >Re: Coredata and threads (From: Jeff LaMarche <email@hidden>)
 >Re: Coredata and threads (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: Re: MainMenu
  • Next by Date: Re: perform ... afterDelay?
  • Previous by thread: Re: Coredata and threads
  • Next by thread: Re: Coredata and threads
  • Index(es):
    • Date
    • Thread