[SDL] What are threads allowed to do?

Bob Pendleton bob at pendleton.com
Mon Jan 24 11:48:22 PST 2005


On Mon, 2005-01-24 at 12:40 -0500, Albert Cahalan wrote:
> 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.

As long as you use the same tool chain to build your code as you would
use to build SDL you are fine. SDL, obviously, uses threads and works
just fine.

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

That means video and anything that may be called by the video code.

I can't answer that question without a detailed analysis of software
surface code; I'm pretty sure (I have been in that code recently) that
if you put a wrapper around them you can call the those functions safely
in any thread. I would put a wrapper around any graphics code I used in
another thread. The problem is that some low level SDL code uses lower
level graphics code without going through the high level APIs. 

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

One of us has to be right :-) I've found that being pessimistic in cases
like this save me a lot more time than being optimistic.

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

What, you want to create a thread per font? Not a problem, read the font
file into memory and open it with TTF_OpenFontRW (use a wrapper around
it to serialize use) and you can load the fonts in parallel and you only
get serialization when you open the font. Or, just use a thread the
sequentially call TTF_OpenFont(). So long as it isn't being called
anywhere else, there is no problem.

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

Yep, and if you are trying to read many files at once you might get
better use of the disk. 

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

That is an obvious use of threads and should work if the scanning thread
is properly structured and take proper precautions when using SDL and
your own internal code and data. 

This use implies that there will be data and code within your own
program that will have to have mutex protection.

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

Man, you would be surprised at the amount of local state that is kept in
global variables. 

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

Which is wonderful. But, so long as you are using the SDL wrappers you
can't be sure of what the wrappers do. BTW, there have been some recent
fixes in memory handling in the SDL_TTF library. You might want to use
the latest CVS versions of the code.

		Bob Pendleton

> 
> > We're going to need thread safe versions of all the libraries we use.
> 
> Yup.
> 
> 
> 
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
> 





More information about the SDL mailing list