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: Luke Evans <email@hidden>
- Date: Sun, 22 Feb 2009 12:46:31 -0800
Indeed.
I certainly saw all the references you highlight, many times. I am
not saying there aren't warnings, and true, "suckered" implies an act
of inducement on the part of the documentation, which certainly is not
there.
However,
"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)."
(and the others) told me that I was choosing an option that required
programmer discipline - perhaps a harder path, but one that remained
practical if you were willing to be liturgical about locking.
My discovery (and life is full of them, so nothing particularly
unusual here) is that the practicality of doing the locking appears to
'tip over' if you have binding to your Core Data. I have my main
thread, and one background thread trawling for files - both
scrupulously locked on the MOC around _any_ access, i.e. even reading
a property. At the time, I considered this to be conformant to the
documentation that strongly discourages the approach but nevertheless
discusses it while warning about the need for locking diligence... but
you live and learn. AFAICS, locking the MOC like this does seem to be
at least a viable option (saying nothing of its ergonomics) if you
don't use binding to UI controls. There's perhaps yet more locking
you can do in various UI-related hooks that would yet make this work,
but I think the code torture level really crosses an acceptable
threshold somewhere along that line (I had the briefest look at how to
get in between the MOC signaling KVO notifications and the controllers
updating the UI).
If I have a enduring comment about the relevant docs, it would be that
I wouldn't have tried to use this technique in the first place if I
had read that it was essentially incompatible with binding. That
would have overcome what was, in retrospect, taking the warnings too
lightly. Still, you can't practically expect docs to universally dot
every 'i' and cross every 't'. Thankfully, we have mailing lists and
the like.
Anyway, life moves fast and so does code - now that I'm educated,
despite what you might think was a blind impetuousness to use a
feature that was "strongly discouraged", my code is having all its
Core Data access done on the main thread.
-- lwe
On 21-Feb-09, at 7:47 PM, mmalc Crawford wrote:
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