Re: Need some advice on multithreading
Re: Need some advice on multithreading
- Subject: Re: Need some advice on multithreading
- From: WT <email@hidden>
- Date: Mon, 24 Nov 2008 11:08:59 +0100
Hi Mike,
thank you for taking the time to answer my post.
>> 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.
I have now gone through both podcasts and, frankly, the first one
didn't provide me with much that I didn't already know. As it happens,
I have quite a bit of experience programming multithreaded apps in
Java so I knew all the basics already. What I needed (and still do) is
some more Cocoa-specific guidance, something like the best-practices
of thread programming in Cocoa.
>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.)
I rather enjoyed the second one. If and when I need to optimize the
performance of the simulation engine itself, I might consider using
some of the techniques discussed in that podcast.
>- 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.
Is that the general consensus? I've now seen a few examples and they
all seem to work fine. Then, again, extrapolating from a small sample
is always dangerous...
>- 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.
Generally, I'd agree with you on what you just said, but I have to
disagree this time because I am not using multithreading for the
purpose of optimization. I'm using it because it's a requirement that
the user should be able to change certain aspects of the simulation
while the simulation is running. For instance, in the example of the
bouncing balls, if the user were to rotate the container (the custom
NSView), the balls should continue moving, rather than stop until the
user has finished rotating the view. This requirement necessitates a
complete separation between running the simulation and dealing with
user events, and that spells multithreading to me.
>- 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.
Yes, I'm aware of the problems you mentioned. My application, however,
will likely not suffer severely from those problems, since the data
sharing in it fits the producer/observer pattern, as opposed to a
model where several threads all read and write shared data. The UI
produces values that must be passed to the simulation engine and the
simulation engine produces data to be displayed. The simulation engine
never writes back to the UI controls and the drawing engine never
writes back to the simulation engine. The flow of data is always
unidirectional. This model (producer/observer) is the ideal case to
apply messaging but there is still the issue of when the new data is
inserted into the current thread. Message-passing and immutable
objects do not necessarily solve the issue of data synchronization.
What I need is a way to guarantee that new data will not be inserted
in the middle of the simulation (or drawing). In Java, I'd fire the
notification message in a separate thread and would make sure that it
blocks until an appropriate lock is released. In Cocoa, I was hoping
not to have to get down to that level of detail and, instead, simply
take advantage of the ability to set dependencies between NSOperation
objects added to an NSOperationQueue. (Yes, I know that, deep down,
NSOperation and NSOperationQueue may use threads and locks and all
that good stuff to do their magic. The point is, *I* don't want to
have to deal with that level of detail, if I can help it).
>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.
Ok, now, that's something I didn't know and which is very useful to
know. Thanks!
_______________________________________________
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