Multithreading

Hello,

I am currently making a multithreaded program which use SDL, but I have
a problem.
I use some SDL video functions in one of my threads, and I would like
to close my SDL window when I kill my thread. SDL_Quit close all the
application, and I don’t see any other way to close my SDL Window. Could
you help me please?

Julien

Hello,

I am currently making a multithreaded program which use SDL, but I have
a problem.
I use some SDL video functions in one of my threads, and I would like
to close my SDL window when I kill my thread. SDL_Quit close all the
application, and I don’t see any other way to close my SDL Window. Could
you help me please?

SDL_Quit() shouldn’t close your application.
If you are using SDL 1.1, you can try SDL_QuitSubsystem(SDL_INIT_VIDEO);

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Hi,

Firstly, I’d like to say that the problem I was having before with SDL
not restoring the normal X-Windows video mode in Linux was 100% my fault,
and in fact did not require the hack that I used and mentioned a few days
ago. I just made a C++ programming error of forgetting to delete the
dynamically allocated object whose destructor calls SDL_Quit(). So,
SDL_Quit() was never actually being called. Sorry for screaming fire…

Anyway, my question now concerns the relative benefits of multithreading
in a game vs. one big main loop. Multithreading obviously adds
complexity and a lot of extra work for the programmers involved in the
project. Is it really worth it? With computers running over 350 MHz
these days, a lot can be accomplished in one big main game loop, it seems
to me. Where do people recommend a multithreaded implementation vs. a
single-thread. I know it’s recommended that the rendering be performed
in the main thread. But what about music, sound effects, AI, and event
handling? My first instinct tells me to avoid multithreading like the
plague. Especially with C++ exceptions, things get messy quickly.
Thoughts?

Thanks,
Curtis


  • Curtis S. Cooper, Graduate Research Assistant         *
    
  •  Lunar and Planetary Laboratory, University of Arizona  *
    
  • Kuiper Space Sciences, Rm. 318                        *
    
  • 1629 E. University Blvd., *
  • Tucson, AZ 85721 * * * * * * * * * * * * * * *
  • Wk: (520) 621-1471 *

At 09:25 PM 8/9/02 -0700, you wrote:

Anyway, my question now concerns the relative benefits of multithreading
in a game vs. one big main loop. Multithreading obviously adds
complexity and a lot of extra work for the programmers involved in the
project. Is it really worth it? With computers running over 350 MHz
these days, a lot can be accomplished in one big main game loop, it seems
to me. Where do people recommend a multithreaded implementation vs. a
single-thread. I know it’s recommended that the rendering be performed
in the main thread. But what about music, sound effects, AI, and event
handling? My first instinct tells me to avoid multithreading like the
plague. Especially with C++ exceptions, things get messy quickly.
Thoughts?

IMHO, use threading only for tasks that are truly parallel, and require a
minimum of communication between themselves. If, for example, you’re doing
several independent computations that will last for the duration of
execution, you may want to spin them off into threads. Network and event
code may be a good example of this, but only if you write it such that your
events don’t need immediate processing by other threads. Remember,
multithreaded code means that there are no order-of-processing
guarantees, so your data will be in an inconsistent state if you need to
access it through anything but the ‘owning’ thread. (Side note, that just
comes to mind – you may want to thread out anything that blocks on slow
[disk] IO.)

I highly recommend not generating and destroying threads on the fly, in
the middle of your program – if you’re not coding absolutely perfectly,
this can and will lead to problems.

Using threading will further erode any kind of real-time restraint you put
on your program – if you want/need something completed in 50ms, it’s
easier to complete it in that timeframe with one thread than trying to get
the processing done with many more scheduler calls involved.

If you go with multithreading, keep the actual work done in each pass (as
in loop) of the thread relatively small before you call a SDL_Delay(foo) –
do not rely on Operating System preemption to do your multitasking. If you
wait for the operating system to yank control from your threads, you’ll end
up with relatively choppy behavior as the threads stagger along.

In your exact situation, taking gut-feeling guesses:
Music doesn’t need to be spun off, probably. SDL_Mixer, I believe,
offers a callback for when the music’s done playing, which is (so far as I
know) already multithreaded – just use that to reload/loop music.
Sound effects – no. Bad idea, really – the sound effects are part of
the interactive processing, and unless you really want to try to manage a
queue of effects to play, it’s a good idea to keep the effects in your main
processing thread.
AI – it depends on what you’re writing. I’d be inclined to say no if
the AI involves access to changing data, as in a realtime game, because
then you get into some fairly complex locking issues through trying to
guarantee a consistent state for processing. On the other hand, for
something like a turn-based game it may be a good idea: Stardock’s Galactic
Civilizations for OS/2 used multithreaded AI for the computer to make its
decisions during the (relatively slow) player’s turns, to devastating
effect – the extra time [given by not being under pressure to speed up
turn-generation] was used to run through the equivalent of huge switch/case
statements so a relatively simple AI could respond to some interestingly
complex situations.
Event Handling – possibly, again. In a multithreaded environment, you
stand to lose nothing by having a thread wait on each event to come
in. However, this thread will be able to do little but raise a flag for
the rest of the processing to get to in its own time, unless you want to
throw mutexes all over the place, which defeats the purpose of
multithreading in the first place.

Ah, forgot exceptions:

Firstly, you probably should not be using exceptions for anything but
error-checking, anyway – it should not be a means of messing with control
flow, that’s what variables, if-statements, and the goto are for.

Secondly, don’t C++ exceptions just unwind the local stack until it gets to
something that will handle the exception? If so, then your largest worry
would be an exception that travels far enough out for you to ‘lose’ a
thread whose handle you’ve stored in a stack-local variable. The solution
here is quite simple – don’t do that.

Realtime terrain generation.
Becouse it’s hard to have few GB of terrain data in RAM.On Sat, Aug 10, 2002 at 12:51:46AM -0400, Christopher Subich wrote:

IMHO, use threading only for tasks that are truly parallel, and require a
minimum of communication between themselves.


http://decopter.sf.net - free unrealistic helicopter simulator