Question

I’ve created a system where i can request an NSManagedObjectContext from a singleton object, dependant on the queue it’s running on. Every serial GCD dispatch queue is associated with a certain task, and thus gets its own context, though all with the same persistent store coordinator.

I was under the assumption that this would solve my problems associated with threads, which it so far seems to have done, but now i have a different problem: If 2 serial queues, with different MOCs, both try to make the context execute, they both lock and the app freezes. So what did i miss?

“…[I]f you create one context per thread, but all pointing to the same persistent store coordinator, Core Data takes care of accessing the coordinator in a thread-safe way (the lock and unlock methods of NSManagedObjectContext handle recursion).” (source)

What i read there, is that Core Data should handle locking and unlocking correctly with my setup. Or do i understand ‘in a thread-safe way’ wrong in this case?

Edit: I basically have a dictionary that maps a queue to a context. At first i wanted to work with threads instead of queues, until i read this part:

“Note: You can use threads, serial operation queues, or dispatch queues for concurrency. For the sake of conciseness, this article uses “thread” throughout to refer to any of these.” (source)

Answer 1

JeremyP is right: queues do not == threads. A queue may create a new thread for each operation – Core Data (in the default mode) requires thread confinement (that is, the thread that created the NSManagedObjectContext must be the thread used for all access to any objects from that context).

You may want to check how the confinement options are used – if you’re targeting iOS5 alone, you might be able to change it without too much difficulty and still use the queues.