SDL_Delay stops all running threads?


#1

Hello, my doubt is that above, because I’m trying to run my game with the game’s code in another thread but something that I never seen with SDL happens:
the SDL_Delay stops the running game’s code thread. Render in the main function.
In my game I want two main threads: game’s rendering and coding. But, I can’t use the code thread because I need to wait some time because the thread runs very fast and the game too. So I put a SDL_Delay in each thread but so the game waits two times. I tried to put only one delay in the code thread but so the main render takes to much processing.

So, how can I split my game in two main threads with the correct delay and without loose performance?


#2

That is not possible, there can only be one main thread. Running your game in one thread and the renderer in another is possible, but it can have its drawbacks.

As for your question, SDL_Delay should only pause the execution of the thread that called it.

This is a matter of preference, and you’ll mostly get opinions in my opinion. The horrendous nightmare that is thread management is going to drive you mad and The wonderous world of using threads is a very fickle beast that will takes a lot of work to get right. You can try using semaphores to tell each thread when work is available, this can get tricky and lead to program deadlock. You can also try mutexes, which will lock off portions of your code, which is really good for using flags; however this can lead to deadlock. Both of these can also potentially lead to livelock. I don’t want to scare you away from threading, but warn you that it’s a very VERY scary beast that is not easily tamed; but can be worth it if done properly.

Personally, I’m using both, and the best advice I can give you is to caution you to use the timeout functions to help reduce possible locking. By using the timeout functions, you also have the ability to detect when the program is shutting down so that you can exit the thread properly.


#3

@Blerg, thank you for your answer. So, my game is taken almost processing, and the high coast is the update of the game’s classes. I tried to separate in other thread but the high processing still continues, well, I’ll use the main to update my game because in the moment threads don’t make difference.

But oone last question: how can I use SDL_PollEvent without remove events from the event poll? I try the two threads and in each thread I use one SDL_PollEvent, calling in each one it don’t let the other read the event because SDL_PolllEvent consummates the event. So, I made a gambling: just reput the event to the event poll but sometimes I get undefined way.


#4

SDL_PollEvent can really only be called from the thread that initialized the video subsystem. It may just be silently failing in your other thread.

SDL_PollEvent
As this function implicitly calls SDL_PumpEvents(), you can only call this function in the thread that set the video mode.

SDL_PollEvent() is the favored way of receiving system events since it can be done from the main loop and does not suspend the main loop while waiting on an event to be posted.

Personally, I use vector containers to pass data from thread to thread, just surround it with mutex timeout un/locks to keep it from crashing when things are added/removed. In my program, the system checks for changes/work, and if it doesn’t find any it does an SDL_Delay. When it’s idling about, the processor usage is very low.


#5

Ok @Blerg, thank you again for the answers. I will do more tests with threads until decide what to do.