SDL Program not responding(is handling events)

[Disch]

Multithreading is needed if command input, background processes, networking , graphics and event handling should be possible to have at the same time.

This is technically true, but the real question is do these things really need to happen at the exact same time, or can you just do them serially? The only one of those that sounds like it might need its own thread is the networking (because that often involves blocking calls) and maybe 'background processes' -- but that's kind of vague. The rest really should not have a dedicated thread.


Here are some points about multithreading that I'm assuming you may not know (judging by this problem you're having and the fact you say you're only using one semaphore in the entire program):


-) Multithreading opens up tons of possibilities for race conditions which create really nasty, hard to reproduce bugs. If you only have one semaphore -- this hanging problem will likely be the easiest multi-threading related bug you'll have to fix.

-) To avoid these kinds of bugs, any memory that is critically accessed by multiple threads potentially at the same time must be guarded by some kind of locking mechanism (a semaphore counts as a locking mechanism). In your example function, it looks like stdfont and stdscr are being accessed by multiple threads. If that's the case, all accesses to them in all threads must be guarded.

If you are not doing this, your program will behave very strangely. What's worse is it will behave strangely intermittantly -- that is... sometimes (maybe even most of the time) it will work just fine. But every once in a while it'll just start acting really weird.

-) Synchronizing threads is slow. Very slow. By this I mean that whenever you have to lock a mutex/semaphore to safely access shared memory, there is a huge performance hit. If a lot of your logic requires interdependency on work being done across multiple threads, this could result in your multi-threaded program running much slower than a single-threaded counterpart. (ie: multiple threads doesn't automatically translate to "faster").

If you end up thrashing between multiple threads waiting for work to get done, your program might slow to a crawl.









All of that said... I don't know the needs of your program so multi-threading might be justified. I just want to make sure you know the tradeoffs. Personally, from my viewpoint of what I'm seeing in this thread... I really think you should not be doing any multithreading at all. Your program will be much simpler (and maybe even just as fast or faster) if you run from a single thread.




EDIT:


Not too long ago I actually did some timing benchmarks in an emulator I was working on. You can see the numbers here:

http://forums.nesdev.com/viewtopic.php?p=96069#p96069

"Cooperative" is multiple threads being simulated in a single thread.
"Preemptive" is true multithreading.

As you can see from the numbers, the single threaded approach was significantly faster because of all the sychronization required. Now you may not be syncing as much as I was... but this is a pretty clear indicator of just how slow inter-thread synchronization is.

[TheBreadCat]

Thanks for the information. The reason why I went crazy with all the threads was because I was setting up a framework that should be modular and dynamic. But I'll try to get the same functionality without to much multithreading.

[TheBreadCat]

It worked. Keeping the threads down to a minimum solved it.