Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).
Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).
- Subject: Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).
- From: mmalc Crawford <email@hidden>
- Date: Sat, 21 Feb 2009 19:47:38 -0800
On Feb 20, 2009, at 3:25 PM, Luke Evans wrote:
OK, that's too bad. I was suckered into thinking that following a
locking regime (one of the suggested "how to use Core Data in a
multithreaded environment" approaches) would allow things to work
satisfactorily and provide the freedom to mutate the model on any
thread so long as MOC level locking was done diligently.
It's not clear how you might get "suckered" into following a locking
regime -- the documentation consistently discourages this approach,
e.g.:
"If you try to pass actual objects, share contexts between threads,
and so on, you must be *extremely* careful about locking (and as a
consequence you are likely to negate any benefit you may otherwise
derive from multi-threading)."
<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdMultiThreading.html
>
(Emphasis in original.)
It immediately goes on in a similar vein to the rest of the article:
"Working with a managed object across different threads is therefore
strongly discouraged..."
I have to say that I was surprised to find that simply asking
executing a fetch request caused the MOC to hijack my call and go
off to write to controllers, but I suppose that has to happen in
order to ensure the correctness of my result (in case there are
pending changes in the controller - though wouldn't that be a _read_?
"Thread Safety Fundamentals
There are several issues to bear in mind when using multi-threading in
a Core Data application:
• Any time you manipulate or access your object graph, you may be
using the associated managed object context.
Core Data does not present a situation where reads are "safe" but
changes are "dangerous"—every operation is "dangerous" because every
operation can trigger faulting."
mmalc
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden