[SDL] patch for SDL_rotozoom.c

CRV§ADER//KY crusader at inwind.it
Fri Nov 28 05:45:01 PST 2003

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

> 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

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

> (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
+ Bob Pendleton: writer and programmer. +
+ email: Bob at Pendleton.com              +
+ web:   www.GameProgrammer.com         +

More information about the SDL mailing list