[SDL] What are threads allowed to do?

Albert Cahalan albert at users.sf.net
Mon Jan 24 09:40:47 PST 2005

On Mon, 2005-01-24 at 09:03 -0600, Bob Pendleton wrote:

> Taking a shot in the dark here... Since no one can know what you know we
> have to take shots in the dark. 

Yeah, I know. Thank you for trying.

> On linux, the C/C++ standard libraries may or may not be thread safe, it
> all depends on the version you use. If you are on 3.0 or better then the
> standard libraries are thread safe (at least that is what the docs I
> have found say and it seems to work).

This is plain C, not C++. I have various gcc versions from 2.95 to 3.4,
with glibc 2.3.2, and old-style Linux threads.

> OTOH, SDL is not thread safe. All graphics must be done in the main
> thread

"All graphics", hmmm? Does that mean just video, or allocating
and freeing software surfaces too? I had also been hoping to
load and scale some images in a thread dedicated to clip-art.

> But, like I said, SDL is not thread safe, neither are any of the SDL add
> on libraries. If you want to use them in threads you have to build
> wrappers for the code you want to use.

I think somebody else just said the opposite. :-(

> What does that mean to an SDL programmer? It means that you can have 10
> threads reading 10 files, but only one thread can be decoding a ttf font
> at a time.

This is awful. I looked over libSDL_ttf and didn't find anything
significant. What did I miss? I saw:

a. error text might get corrupted (but no crash)
b. can't do simultaneous TTF_Init() calls (no problem)

Regarding #a, note that libSDL_ttf does not pass '%'
in error strings. So the unsafe vararg stuff in SDL's
error handling would not be involved.

> Now, the thing to consider is that unless you have a hyperthreading or
> multicore CPU you can't actually have more than one thread active at a
> time anyway. And, having multiple threads reading from a single disk may
> or may not improve disk reading performance. After all, there is only
> one disk to perform the reads. So, this month you might not see the
> performance improvement you expect to see. Next month you might see a
> dramatic performance improvement :-)

Raw performance is a tiny bit better. I suppose this is because one
thread can use the disk while the other uses the CPU.

Apparent performance is dramatically improved. The user can start
using the app while fonts continue to load. If the user quickly
tries to use the text tool they'll see a progress bar and have to
wait a bit, but they can use every other part of the app without
waiting for the font scanner.

> Just and editorial comment or two if you don't mind: Thread programming
> in user space is very different from thread programming in system space.
> The main difference is that in system space everything has been coded
> assuming multiple threads because of interrupt processing. In use space
> almost no code is written assuming multiple threads. Most libraries will
> turn there toes up and die if you try to use them in a multithreaded
> application without writing a serializing wrapper library.

Ouch. I expected this of init functions and functions with an API
that is inherently unsafe (like strtok).

FreeType solves this as a side-effect of being ROMable. There is
no static data in the library.

> We're going to need thread safe versions of all the libraries we use.


More information about the SDL mailing list