[SDL] What are threads allowed to do?

Eric Vidal evidal at ateneo.edu
Fri Jan 21 00:50:19 PST 2005

> Mere guidelines alone don't make for solid software. Am I to assume
> that all other SDL functions are unsafe? The same for C library stuff
> on the various supported platforms? If this is the case, then threads
> are quite useless.

I suppose there has to be a better list of guidelines, then.

I've been doing cross-platform multithreading in SDL for quite some time 
now, and about the only snag I hit is memory allocation across multiple 
threads (and I've only experienced that problem in Windows).  I do use 
standard C library functions across threads, so that makes me a 
rule-breaker.  ;)

I may be wrong, but I think the only reason for the "don't call library 
functions in separate threads" is because some of those library 
functions change an implicit "state" in SDL's own space, such that a 
program may enter and exit that state only through the same thread.  For 
example, you shouldn't call SDL_LoadWAV and SDL_FreeWAV in separate 
threads because these functions implicitly do memory management 
themselves, but theoretically you should be able to call both functions 
on the same wave data array in the same thread.  (I haven't actually 
tried breaking that rule, though -- I ended up coding pessimistically 
for this case and so I've never tested allocating memory using a thread 
other than the main one.)

> I tried using threads, hit memory corruption problems, and...
> well, what am I to do? I can not even determine if my own code
> is correct if thread-safety of various library functions is
> undocumented. Really, it is completely unsafe to use threads
> without documentation. I went with the optimistic approach, but

I don't really know if documenting every single SDL function whether it 
is thread-safe is actually feasible.  As a corollary, the Java language 
inherently supports multithreading, but it doesn't have documentation 
for every single function (and there are many of those in Java!) telling 
us whether it is thread-safe either.  But somehow that works well 
enough.  :)

I would think that using the thread-locking mechanisms should already be 
a safe bet, and instead there should be clear documentation whether a 
library function behaves in a state-dependent manner ala 

Offtopic:  I noticed that the Windows version of SDL uses the Win32 
mutex objects.  From what I've read, those are only useful for 
inter-application synchronization, and critical sections should be used 
instead to save some resources.  I've recompiled SDL using critical 
sections and things are indeed a bit snappier -- I'm actually getting, 
like, one more frame per second in my app.  :)  I haven't really 
profiled my code yet, but it seems that each thread was able to do just 
a little bit more in the same timeslice it gets from the processor, 
(perhaps because it doesn't have to compare any mutex "names"?  Not that 
it matters, SDL already passes NULL for the mutex name...).  Is there an 
argument for leaving the SDL implementation at mutexes?  I don't think 
it would really break most applications except for those which had some 
sort of internal behavior relying on an extremely "perfect" sync (which 
would probably break on a different processor anyway).  Oh, and I can 
send in a quick patch if you do want the critical sections instead.  :)

Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University

More information about the SDL mailing list