Thanks Ken.
Yes, I'm intending to experiment with the multiple-context approach
now. I had a few questions about this (posted earlier in the thread),
but they're only really soliciting for thoughts on best practice using
that technique - and nothing I wouldn't discover through
experimentation.
I had thought the locking would be relatively contention free, seeing
as almost all the interaction with the MOC was happening on the main
thread anyway, and I just had a background thread for a single
function, that would only find relevant files once in a blue moon - at
which point all that locking everywhere would allow a simple update to
the MOC from that thread. I was completely ignorant of the effect of
the binding to UI controls though, which I believe was the Achilles'
heal - in this specific case.
Agreed on shared memory point in general, but of course there is
almost always a need to exchange data (which very frequently comes to
you as some memory reference, and whose contents you are supposed to
obtain via methods). I'm still learning what things can be safely
exchanged, even when supposedly 'reading'. For instance I just
discovered that extracting an NSImage's representation from background
threads to use in a CIImage can be deadly (apparently using it causes -
[NSBitmapImageRep getBitmapDataPlanes:] to _loadData which I assume
isn't thread-safe - though I need to properly figure this one out).
Naturally, it's unrealistic to expect documentation of all the
behaviours that objects have vis-a-vis threading (though Apple have
guidelines), but whenever you create some kind of concurrency you have
to think about what objects/states will specify its operation and
whether these will be safe to pass themselves. Anyway, I digress.
It's patently clear in the case of MOCs that locking is only viable in
some benevolent conditions, which are not those I thought I had :-)
-- lwe
On 22-Feb-09, at 1:51 PM, Ken Ferry wrote:
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.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
