On Sun, Nov 23, 2008 at 7:06 PM, WT <[EMAIL PROTECTED]> 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 (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 [EMAIL PROTECTED]
