Multithreaded programming

i’m considering altering my graphics application to use multithreading as supported by SDL, but i’m a little concerned about the warning about allocating memory in multiple threads. i can see how this would be an issue, but i can also see how this would be something that multithreading system would handle.

the multithreading docs are pretty sparse… anybody have practicle knowledge of the hows and whys here?

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? is the problem more or less severe based on the target operating system (i know MacOS doesn’t really support multithreading, but i’m curious if some systems do better than others – for example, i know IRIX is very good about shared memory allocation).

thanks for any pointers!

-miles vignol

i’m considering altering my graphics application to use multithreading
as supported by SDL, but i’m a little concerned about the warning
about allocating memory in multiple threads. i can see how this would
be an issue, but i can also see how this would be something that
multithreading system would handle.

This is one of those questions where the answer is going to depend a
great deal on which compiler and OS you are using. I researched this for
GCC on Linux and found that sdl-config “does the right thing” and sets
the right flags to solve this problem for you.

Basically there are two versions of the C libraries. One that works with
single threaded programs, and another where the calls are all wrapped
with a mutex to prevent them from being run by multiple threads at the
same time. (At least it acts that way.) So, if you use “sdl-config
–cflags” to compile your code you get the right library and everything
works just fine because it defines _REENTRANT. So you can malloc from
multiple threads without problems because only one thread is allowed to
access malloc at once.

You can get into some weird debugging problems because adding print
statements to you code forces some level of serialization and the code
behaves differently with the prints in than it does when they are
removed. :slight_smile:

the multithreading docs are pretty sparse… anybody have practicle
knowledge of the hows and whys here?

Yeah. Done a lot of it.

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.

is the problem more or less severe based on the target operating
system

Yes. The semantics of threads are different from OS to OS and are
different from implementation to implementation. For example, Java has a
couple of different thread models and I can tell you that code that
works under one model will not work under the other one.On Wed, 2003-11-12 at 02:05, Miles Vignol wrote:

(i know MacOS doesn’t really support multithreading, but i’m curious
if some systems do better than others – for example, i know IRIX is
very good about shared memory allocation).

thanks for any pointers!

-miles vignol


±--------------------------------------+

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.
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.

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?

thanks again,

-miles vignol

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
fine.

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
provide.

thanks again,

-miles vignol

	Bob Pendleton

P.S.

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.On Wed, 2003-11-12 at 15:04, Miles Vignol wrote:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±--------------------------------------+