Hi guys,
I have been working on my current code base over a month and recently
started having random crashes. I tracked these down to the fact that
SDL_PollEvents is not thread safe, which is really odd because it has
been working fine for several weeks and just started causing
corruptions a few days ago, and am now left with the need to change
the way my code functions. As I want to modify the code a little as
possible and want my code to run as fast as possible I want to ask you
what the best option would be. I have this down to two different
methods I could use to handle this. But do not know what would work
best for SDL, and games in general.
The two main options for fixing this I see would be to either change
my code so that the Input class is run along side, well in the same
thread, as the display class or too poll for the events and pass them
to the input class. Now the main issue with the first method,
combining, is that it messed up code base and would wind up be a day
or two project to make everything integrate well and look proper,
rather then just the hour hack it would take to get the code running
this way. On the plus side I would most likely see a performance gain
from no longer using mutexs, which seem to be taking up a large
portion of my code’s run time. The second method would allow me to
keep all of my code base, with only two new functions added, and would
be able to be put in quickly. The main issues here are that I would be
needing to lock and unlock mutex many more times, to the point it
might even be spending more time with them then running. Also the
method just screams hackishness to me.
I am currently leaning towards spending the time and rewriting the
code so that it will run in a single thread and still support multiple
threads so I can later add them for things such as sound, networking,
physics, and AI. But I am wondering if I am missing something, and if
there is a way that using my current code base I can fix the
corruption issue.
Thanks,
Brandon
According to the SDL doc wiki…
SDL_PollEvent: “As this function implicitly calls SDL_PumpEvents, you
can only call this function in the thread that set the video mode.”
SDL_SetVideoMode: “This function should be called in the main thread
your application.”
This limits the amount of threading that you can do, as the graphics
and input must be handled in the main() thread. However, you can use
your own threads for other tasks.
http://www.libsdl.org/cgi/docwiki.cgi/SDL_API
http://www.libsdl.org/cgi/docwiki.cgi/SDL_PollEvent
http://www.libsdl.org/cgi/docwiki.cgi/SDL_SetVideoModeOn Fri, Apr 10, 2009 at 9:44 AM, brandon stevenson wrote:
Hi guys,
I have been working on my current code base over a month and recently
started having random crashes. I tracked these down to the fact that
SDL_PollEvents is not thread safe…
But I am wondering if I am missing something, and if
there is a way that using my current code base I can fix the
corruption issue.
poll for the events and pass them
to the input class.
[snip]
The main issues here are that I would be
needing to lock and unlock mutex many more times, to the point it
might even be spending more time with them then running.
You shouldn’t need a lock/mutex to pass messages from one specific
thread to one other specific thread. A simple “ring queue” construct
that is carefully written will allow you to pass messages without
locking in one direction between a specific pair of threads. Watch out
for overruns, though…
I guess I don’t really know what “input” means to you, or exactly what
your “input class” is, but I can’t see a good reason for handling this
in a separate thread. Why is it in another thread?
I am currently leaning towards spending the time and rewriting the
code so that it will run in a single thread and still support multiple
threads so I can later add them for things such as sound, networking,
physics, and AI.
Why do you want to use so many threads? The only good reason to
separate several of the tasks you mention (and it is a good reason) is
to take advantage of parallel processing cores. In this case, I would
recommend reading about programming highly parallel systems and how to
effectively use thread pools to offload tasks to parallel processing
cores in a way that is abstracted away from a low level threading API.On Fri, Apr 10, 2009 at 4:44 AM, brandon stevenson wrote:
–
http://codebad.com/
err… well I guess you can also seek better latency in these cases.
If you use SDL audio, then that already uses asynchronous callbacks
for doing sound, and may in fact use a separate thread.On Fri, Apr 10, 2009 at 3:39 PM, Donny Viszneki <@Donny_Viszneki> wrote:
I am currently leaning towards spending the time and rewriting the
code so that it will run in a single thread and still support multiple
threads so I can later add them for things such as sound, networking,
physics, and AI.
Why do you want to use so many threads? The only good reason to
separate several of the tasks you mention (and it is a good reason) is
to take advantage of parallel processing cores. In this case, I would
recommend reading about programming highly parallel systems and how to
effectively use thread pools to offload tasks to parallel processing
cores in a way that is abstracted away from a low level threading API.
–
http://codebad.com/