Avatar of qff
qff asked on

SDL: threaded application design

I'm making a game, programmed in C++ with SDL and some use of the boost libraries.
I am aware of the pitfalls of multithreaded application development (at least somewhat aware).

My plan is to have event-handling, drawing and game mechanics running in seperate threads.
I'm thinking about letting the event-handler spawn a new thread to make the appropriate response to a caught event - so the event-handler is not interrupted or halted for too long each time an event occurs.
Should I use SDL_WaitEvent or SDL_PollEvent in this case for checking events?

My question is whether I'm on a wrong trail here (am I doing it completely wrong?).
If you have any suggestions to improve my application design (or if you simply have a better one), I would love to hear them.
I'm currently planning to use SDL threads - would I be better of with boost.thread?
Programming TheoryGame ProgrammingC++

Avatar of undefined
Last Comment

8/22/2022 - Mon

>> would I be better of with boost.thread?
I don't know about better as I've never used SDL but I can tell you that using boost threads is very simple indeed. Below is some example code of spawning and stopping a thread.
#include <iostream>
#include <string>
#include <csignal>
#include <cstdlib>
#include <boost/thread.hpp>
// Thread functor
class thread_func
	thread_func(std::sig_atomic_t & sigQuit): m_sigQuit(sigQuit){}
	void operator()()
		m_sigQuit = 0; // Reset signal
		std::cout << "Running thread" << std::endl;
			// Your work goes here
		std::cout << "Ending thread" << std::endl;
		m_sigQuit = 0; // Reset signal
	// Used to signal thread to quit -- must be a reference!!!
	std::sig_atomic_t & m_sigQuit;
int main()
	// The type sig_atomic_t is thread safe!
	// http://www.cplusplus.com/reference/clibrary/csignal/sig_atomic_t.html
	std::sig_atomic_t sigQuit = 0;
	thread_func tfunc(sigQuit);
	std::cout << "Starting thread" << std::endl;
	boost::thread bt(tfunc);
	std::cout << "Terminating thread" << std::endl;
	sigQuit = 1; // Signal thread to stop
	bt.join(); // Wait for thread to re-join
	std::cout << "Terminating process" << std::endl;
	return 0;

Open in new window


Shouldn't that "std::sig_atomic_t" be "volatile"?
The compiler does not know that the variable can be changed from elsewhere and by your code it is lead to think that it is constant after having been set to "0". The compiler does not take the effects multithreading into account by default - you must tell it that the variable can be changed from elsewhere i.e. "volatile std::sig_atomic_t& m_sigQuit;".

Furthermore I believe that the mentioned atomicity of the specific type does not take multithreading into account either.

>> Shouldn't that "std::sig_atomic_t" be "volatile"?
A reference is really just a pointer in disguise. The value of the reference never changes but what it references does, and therefore making it volatile is unnecessary.

>> Furthermore I believe that the mentioned atomicity of the specific type does not take multithreading into account either.
The type sig_atomic_t can be read/written atomically in 1 CPU cycle, this is guaranteed by the C++ Standard, it is therefore safe to use in asynchronous code in this matter.

Also, it's probably worth pointing out that this is an example that it has been implemented with as little code as possible so as to not detract from the point, which is to show the simple usage of boost threads.
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck

>> A reference is really just a pointer in disguise.

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
Log in to continue reading
Log In
Sign up - Free for 7 days
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.

Thank you for your help ;)