re: Basic Coredata / threading question
re: Basic Coredata / threading question
- Subject: re: Basic Coredata / threading question
- From: Ben Trumbull <email@hidden>
- Date: Sat, 7 Apr 2007 16:03:01 -0700
The app fires off a number of network queries in parallel - each of these is
fired on a separate thread.
Processing network I/O can be a good use of threads.
and execute a fetch which will require coredata to touch nearly every object
in the model.
But you've already lost here. It doesn't matter if you use Core Data
or not, let alone how you use Core Data. You've structured the
problem to ensure defeat.
If every thread truly needs all the (mutable shared) data all the
time, there is no concurrency to be had. You'd be better off writing
a normal sequential program.
This is why thread safe accessor methods are 99% of the time
boneheaded. It's not even mistaking the forest for the trees. It's
more like mistaking the forest for a leaf.
You have a design problem, and adding locks is not going to fix it.
Very few applications actually have the need-everything-all-the-time
problem, so there are probably meaningful ways in which you can
redesign things so that threads only work with part of the data set
at a time. In a meaningful batch size, of course.
As others have pointed out, Core Data makes an effort to share column
data copy-on-write between NSManagedObjectContexts anyway.
If you find that copy-on-write sharing still creates too much memory
pressure, then a dedicated database thread that other threads
communicate with in a very message passing/actor style can be a good
solution too.
That is similar to your original solution, without the deadlocking
bugs. I suspect you didn't adequately isolate the database thread
(i.e. you leaked managed objects to other threads).
Run loops (or simply that style of message queue programming) are a
great way to manage communication between threads, as well as to
cooperatively schedule tasks without threads at all.
Finally, I've been reading "Java Concurrency in Practice" by Brian
Goetz, et al 2006. Even if you despise Java, this is the first truly
exceptional book about nuts and bolts multi-threaded engineering that
I'd recommend. It focuses on actual multi-threaded programming, and
not yet another solution for the dining philosophers.
Introduction to parallel programming books are hard to come by as
most are focused on the academics and science of the domain. Which
is interesting to me, but they don't provide concrete information
about writing thread safe init methods, when to avoid using thread
local variables, or how memory references get reordered. There's
even a section on why GUI toolkits are largely not thread safe.
"Java Concurrency in Practice" is focused precisely on real world
engineering issues, and I strongly recommend it for, well, everyone.
The techniques and problems described are directly relevant to C,
C++, and Objective-C.
<http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/ref=pd_bbs_sr_1/104-9065426-0083159?ie=UTF8&s=books&qid=1175986065&sr=8-1>
and while we're on the subject of reading material, if you've ever
wondered *why* multi-threaded programming is such as pain, here's a
great article by Edward Lee from UC Berkeley:
<http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?path=computer/homepage/0506&file=cover.xml&xsl=article.xsl>
--
-Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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