SDL_Thread vs std::thread

SDL Development
1

Hello there.
I’m developing an application in C++11 which uses SDL2. I’m planning to implement multi-threaded support for my program. Is there a difference between SDL_Thread / std::thread and which one is better to use?

2

You can use whichever you prefer. They work similarly. Keep in mind that SDL is a C library, so it provides SDL_Thread with the understanding that there is no standard C cross-platform threading API for every platform that SDL supports. With C++11, you can use std::thread and expect it to work wherever C++11 is supported. If you’re using C++ to begin with, I would suggest you get used to std::thread, especially as there are further features like futures and scoped locks.

3

Hi,
I have a question about such multi-threaded design.

For example :slight_smile:the main thread creates a window, and its renderer.
It creates a thread (standard or SDL_thread, the kind will depend of the comments of my answer :smile :smile: ).

  1. can this 2nd thread call SDL_CreateSurface, SDL_CreateTexture or TTF_FontSizeUTF8 for example ?
  2. can this 2nd thread call SDL_RenderCopy ?
  3. can this 2nd thread call SDL_RenderPresent ?

The SDL Thread Management webpage indicates "NOTE: You should not expect to be able to create a window, render, or receive events on any thread other than the main one. " but I would like to be sure I can others calls…

Thanks

4

In my multi-threaded app all SDL Renderer, Surface and Texture functions are called only from the main thread (I have implemented a messaging mechanism, based around SDL’s event queue and synchronisation objects, which allows me to ‘call’ those functions from other threads when required).

It would indeed be desirable to have an explicit list of which SDL functions must be called from the main thread, and which need not be, but I suspect such a list is not going to be forthcoming any time soon!

1 Like
5

It would indeed be desirable to have an explicit list of which SDL functions must be called from the main thread, and which need not be, but I suspect such a list is not going to be forthcoming any time soon!

Generally, things in the video subsystem should be on the main thread; often this is not an SDL limitation, but a platform limitation, as several platforms will fail if you try to do GUI things from background threads. Since it’s a platform-specific issue, it’s hard to document beyond “try to do video stuff in the main thread for your own safety.”

1 Like
6

Any SDL function which ultimately calls into OpenGL (ES) is likely to have the limitation. What I learnt the hard way was not to develop your app initially in Windows/Direct3D, because it’s more tolerant of cross-thread API calls than most other platforms and may give you a false sense of security.

7

Hi, rtrussell and icculus. Thanks for comments :slight_smile:

I understand such lilmitations. We can face it also with gtk+ (and a mechanism to help), also in fltk and Qt. So, I got used to have such limitations.

For instance, my app. insure it can’t happen concurrent calls to SDL_Renderxxxx functions from different threads. But probably in the future, some evolution will not respect this rule. I have to take care now.

Thus, there is the way for rtrussell, implementing a messaging system to call SDL_xxxx from the thread which created the renderer. But it is heavy to develop… we must send all parameters of the desired calling function to that thread, serialize them in a buffer, send the buffer, wake-up the thread…

I would like to try a 2nd way, probably easiest to develop : to protect all calls to SDL_xxx by a mutex ? Is that safe enough ?
It will run if SDL hasn’t any context variables internally…

ah …also, my app is running as well under Linux as windows (and maybe rasPI…)

8

I’m afraid that is not going to work. This is what it says in the OpenGL docs: "In order for any OpenGL commands to work, a context must be current; all OpenGL commands affect the state of whichever context is current. The current context is a thread-local variable…". So the requirement to make the calls from the same thread is not (just) to prevent concurrent access, but because of the use of Thread Local Storage.

1 Like
9

Hi, RTRUSSELL,

Thanks for comment. I was aware about that. And I had a doubt about reliability of my app. I’m sure there isn’t any concurrent call to SDL, but anyway, sometimes, some crashes are amazing without obvious reason (even in Linux than Windows). For example inside SQLite lib, even if none databases have been opened…Thus, probably, all librairies are not in clear state.

You confirmed. Thanks. So I will develop your way :slight_smile:

  • designing a mechanism to send SDL function_to_call, and its associated parameters to a “main SDL responsible” thread
  • if I develop something generic enough, I will push it in GPL2

To foum maintainer : is there a way to close thread (forum thread, not SDL :sweat_smile: )