Re: Need some advice on multithreading
Re: Need some advice on multithreading
- Subject: Re: Need some advice on multithreading
- From: "Michael Ash" <email@hidden>
- Date: Sun, 23 Nov 2008 20:31:01 -0500
On Sun, Nov 23, 2008 at 7:06 PM, WT <email@hidden> wrote:
> Hello,
>
> I'm working on an application that simulates some real physical phenomena,
> some aspects of which being under the user's control, and I need advice on
> implementing some multithreaded behavior to improve responsiveness. I would
> like to get some advice, in particular, regarding which tasks I should
> implement as threads or, better yet, as NSOperation or NSInvocationOperation
> objects. I've read the Threading Programming Guide but still have some
> doubts on the best way to accomplish the goals above. I've also searched the
> archives and the post I found closest to what I'm trying to do, yet still
> not helpful enough for me, is
>
> http://www.cocoabuilder.com/archive/message/cocoa/2008/11/5/221957
>
> Elsewhere, I also found these two Late Night Cocoa podcasts
>
> Concurrent Programming
> http://www.mac-developer-network.com/podcasts/latenightcocoa/episode25/index.html
>
> Lockless Thread-Safe Data Structures
> http://www.mac-developer-network.com/podcasts/latenightcocoa/episode32/index.html
>
> but I haven't had a chance to go through them yet, so I thought I'd pick
> people's brains until I do.
Well I suggest you go through those first. You'll find it much more
fruitful to get direct advice from people after you're already
familiar with the basics.
Although I suggest you skip the last one. It's absolutely not "the
basics" in any way, shape, or form. It's extremely advanced techniques
that I recommend that you stay away from forever. (By which I mean
that you should stay away from it until you've advanced to the point
that you're no longer taking my silly advice on what to stay away
from.)
Without getting too deep into the structure of your program, here are
some generic bits of advice:
- First, don't use NSOperationQueue unless you can stand to have your
app crash from time to time, or unless you can require Snow Leopard.
It's crashy and I have no particular hope that Apple is going to make
it stop being crashy at any time in the 10.5 series.
- When multithreading for the purposes of optimization as you're
doing, treat it as any other optimization. That is, measure and
profile your app before you do anything else to it. Trying to figure
out where to put the threads when you don't even know what parts of
your app are slow is pointless. Just as it's a bunch of wasted effort
to carefully hand-craft a super fast assembly language version of a
function that only runs one time for one millisecond, it's likewise a
bunch of wasted effort to carefully come up with a multithreaded
implementation of such a function. In your case, if the simulation
engine only takes up, say, 10% of your CPU time compared to display,
then the absolute possible best speed gain you could ever see from
shoving it into a background thread would be 10%, probably not worth
all the work and risk.
- When multithreading, use message passing and immutable objects as
much as possible. The nightmare case for multithreading is when you
have some gigantic object with a ton of shared state that gets used
from four different threads at once and has a complex hierarchy of
locks to ensure that none of them step on each other's toes. If you
can decompose your operations into individual immutable messages which
you fire across to other threads, you remove a lot of shared data
which is where a lot of the problems with multithreading come from.
NSOperation is actually a nice way to do this, too bad it's pretty
much unusable.
And to answer one question you asked inline, NSNotificationCenter
delivers all notifications synchronously and immediately on the thread
on which they were sent. It is really just a way of indirectly
invoking methods, it doesn't know or care about threads at all.
Mike
_______________________________________________
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