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: Ken Ferry <email@hidden>
- Date: Sun, 22 Feb 2009 13:51:50 -0800
It sounds like you got the idea choosing to lock the context rather than
using multiple contexts would be more efficient, though harder to write.
That was not the intent of the warning. CoreData is designed with threading
in mind, but not by sharing objects between threads. The caution is saying
that the separate-contexts-for-separate-threads approach is likely
to outperform and be easier to write than the context locking approach
unless you're in very specific situations.
Memory accessed by multiple threads is the enemy of multithreaded
performance and correctness. The multiple-contexts approach isolates the
sharing to a well controlled layer in the store.
-Ken
On Sun, Feb 22, 2009 at 12:46 PM, Luke Evans <email@hidden> wrote:
> 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
>
_______________________________________________
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