[SDL] multithreaded programming
bob at pendleton.com
Wed Nov 12 14:34:01 PST 2003
On Wed, 2003-11-12 at 15:04, Miles Vignol wrote:
> > > in general, i'd be looking at splitting off threads to perform
> > > geometric operations on chunks of public data with the result being
> > > more public data. is that a nightmare waiting to happen?
> > Depends on how you do it.
> > Most people start a thread and expect that it will then run in parallel
> > with the rest of your code. They expect it to share the processor on an
> > equal basis. That is rarely what actually happens. Most of the time the
> > thread that is running keeps running. The rule of thumb is that a thread
> > will only run when no other thread *can* run.
> > People seem to think that using threads will make their program run
> > faster. No matter how many processors you have you can never get more
> > than 100% of the available CPU cycles. So, if your code is currently
> > spending a lot of time blocked and only uses a few percent of the CPU
> > then adding threads can make it run faster. But only it they aren't also
> > blocked.
> bob, thanks for the pointers. part of my rationale for multithreading is
> that multi-processor systems would benefit (greatly?) from this technique.
Yes, if you have multiple processors you need multiple threads to get
the maximum advantage from them.
> but the other aspect is that i'm trying to figure out a nice scheme for
> interrupting operations and a seperate thread that gets a signal sounds like
> a potentially clean way of doing things. rather than having to slap UI
> checking code in my process loops, i'd like to just set up signal trapping
> and have the main UI code run in a seperate thread from the processing code
> to handle user interrupts and such.
In SDL the thread that inited SDL must be the thread that does the
graphics. It also has to be the thread the handles input. You can use
the main event loop to send messages to other threads though. And you
can have threads send messages to the main loop.
I assume what you mean is that you want your UI code to update itself
when it gets messages from a long duration processing thread. That works
> this leads me to my next question. obviously i'd rather tell a thread to
> stop rather than just kill it with SDL_KillThread(). it would seem SDL
> ought to have some means of sending signals to threads, but i haven't come
> across any. does the SDL_Thread handle have enough information to extract
> the appropriate information to use OS specific signal handling? is signal
> handling pretty well cross platform?
I'm sure it is possible to work the way you describe, but I have seen a
lot of people try and all of them failed. Set up a nice simple queue.
Create worker threads and have them wait for input on the queue. When
there is input the worker threads can work. When they have output they
can put it in another queue. The master thread (the SDL main loop) can
place commands in the queue. It can wait for the results or it can just
wait for any other input. While it is waiting the worker threads will
work and create output. The master thread can check for the output and
update the UI using it.
So, the answer is that you do not need anything that SDL does not
> thanks again,
> -miles vignol
for an example you might take a look at:
http://gameprogrammer.com/game.html especially fastevents and net2. The
description of fastevents covers a lot of the questions you are going to
have and net2 is an example of using master/worker threads in SDL.
> SDL mailing list
> SDL at libsdl.org
+ Bob Pendleton: writer and programmer. +
+ email: Bob at Pendleton.com +
+ web: www.GameProgrammer.com +
More information about the SDL