0
\$\begingroup\$

I'm trying to set the priority of my threads so that my UI thread can be given priority over background calculations. I noticed that SDL has a SDL_SetThreadPriority method, however I still prefer the standard std::thread syntax rather than SDL_CreateThread. Does SDL_SetThreadPriority work with threads created with std::thread, or do I need to update everything to use SDL_Thread?

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Have you run a test to find out? How did you test it, and what were the results? \$\endgroup\$ – DMGregory Jul 10 '19 at 10:20
  • \$\begingroup\$ I'm not sure how I would test it, is there anything visible you can see to see what a thread's priority is set to? \$\endgroup\$ – Disako Jul 10 '19 at 10:42
  • 1
    \$\begingroup\$ Presumably you could run a counter in multiple threads, then compare the counts they've reached some time later, no? The one with a higher count got more processor cycles, other things being equal. \$\endgroup\$ – DMGregory Jul 10 '19 at 10:46
2
\$\begingroup\$

I did some digging in the SDL source code, and seems like this might vary based on what threading backend you have SDL using. There is a SDL_Thread implementation using the C++ standard library, which like you said does not support setting the thread priority, so in that backend, SDL does nothing.

However, if SDL is running on one of the other backends, there seems to be valid implementations that fetch the currently running thread from the platform, and set its priority correctly. Fro a quick googling it seems that those backends match whatever you would get from std::thread's native handle.

At least on window's SDL_SetThreadPriority is just a call to SetThreadPriority(...), so it might be a cleaner solution to just write your own small wrapper, but using SDL should be just as valid if you make sure that SDL doesn't target C++'s STL threading library as its backend (which it at least for me automatically doesn't). Your own solution could also apply the priority to a specific thread instead of the current one, which at least to me seems like cleaner API design.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.