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 20:39:14 +0100
>> 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...
>
>No, it's not a general consensus. It's something I discovered on my
>own, and posted about it here. I haven't received any overall
>confirmation that it's broken, but my simple test project was able to
>reliably crash on perhaps half a dozen different hardware
>configurations. (And fail to crash on quite a few more.)
>
>If you like, you can go through the original thread here and come to
>your own conclusions:
>
>http://www.cocoabuilder.com/archive/message/cocoa/2008/10/30/221452
>
>If you want to know more about it, please feel free to ask me.
Thanks. I've just read your first post in that thread (no pun
intended!). I'll read the other posts and will try your test shortly.
If I have something useful to add, I'll contact you directly, or post
to the list.
>Depending on exactly what you're after, you might look into other
>facilities provided by Cocoa. If you start a worker thread that runs
>an NSRunLoop, you can then use a method like
>-performSelector:onThread:withObject:waitUntilDone: to execute a
>method on that thread. You miss out on a lot of what NSOperation
>provides, but depending on exactly what you need that may not be a big
>problem. For what you're describing, you could perhaps run the
>simulation from an NSTimer on the secondary thread, then communicate
>the value changes to it using this method.
That sounds like a good solution and, I must admit, it's closer in
spirit to the mental model I have from my Java experience. I'll give
it a shot.
>Have you thought about replacing the main loop of your simulation with
>a timer on the main thread instead of multithreading it? If the
>individual timesteps in your simulation happen fast enough then this
>can be a very good solution. Basically, instead of having a loop that
>does something like "while(!done) simulationStep();", you just set up
>an NSTimer to call simulationStep() repeatedly. The downside is that
>if your individual steps are slow, the user interface will not be very
>responsive, so this is not always a good way to go. I mention it
>because it avoids multithreading and all the difficulties that brings
>along, so it can be nice, but of course it's not always the best.
That's exactly what I had done in the first place, but the results
weren't too good. I then wrote a much simpler app (one bouncing ball)
to test possible solutions and, of course, started with this very
approach. For fun, I allow the user to rotate the container and, sure
enough, the ball hangs in mid-air while I'm rotating the view. And
this, of course, happens regardless of how slow the steps are because
the problem is really that the simulation, the drawing, and all the
event handling all happen in the same thread (the main thread), so
when I'm playing with the slider, the simulation is not running.
I think I'm still going to give NSOperation and friends a try, and
will also try your suggestion of running the simulation on a worker
thread. If nothing else, these will help me learn some more about Cocoa.
Thanks to everyone for all the input.
Wagner
_______________________________________________
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