Jump to content
  • Advertisement
Sign in to follow this  
Hnefi

Threading ones game

This topic is 3725 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've just started working on threading my game, and am looking for advice. I'm using OpenGL through SDL and the boost::thread library. First thing's first: are operations such as writing a value to one of the standard data types atomic? In other words, is the following pseudocode thread safe?
bool done = false;
void Test()
{
 while(!done)
  DoStuff();
}

int main()
{
 boost::thread otherThread(Test);

 while(KeyboardNotPressed)
  DoOtherStuff();

 done = true;

 otherThread.join();

 DeInitialize();
 return 0;
}

Share this post


Link to post
Share on other sites
Advertisement
Writing or reading from standard data types is not atomic.

However, given that "DoStuff" and "DoOtherStuff" don't do anything nasty, the code you've posted is still thread safe, because only one of the two threads writes to "done".

Share this post


Link to post
Share on other sites
So as long as only one thread writes to a variable of the standard datatypes, it's safe? I realize I'll need to use other methods to secure more exotic cases, but if I can do writes from one thread to simple datatypes without using locking mechanisms, it would make things easier.

Share this post


Link to post
Share on other sites
Use a synchronization primitive.


bool shutdownSentinel = false;
boost::mutex mutex;

void Test()
{
while(1)
{
{ /* Establish new scope */
boost::mutex::scoped_lock lock(mutex);

if(shutdownSentinel)
break;


/* INSIDE CRITICAL SECTION */

} /* Mutex will unlock here */


/* OUTSIDE CRITICAL SECTION */
}
}

int main()
{
boost::thread otherThread(Test);

while(KeyboardNotPressed)
DoOtherStuff();

shutdownSentinel = true;

otherThread.join();

DeInitialize();
return 0;
}


Share this post


Link to post
Share on other sites
Quote:
Original post by Hnefi
So as long as only one thread writes to a variable of the standard datatypes, it's safe? I realize I'll need to use other methods to secure more exotic cases, but if I can do writes from one thread to simple datatypes without using locking mechanisms, it would make things easier.


I'm afraid it's more complicated than that. ;)
As long as only one thread writes to one variable of a data type that can be read and written in a single instruction, it's safe. As soon as you expand to more than one variable, the problems start.

So you should definitely look into locking mechanisms, you'll need it sooner than you expect it.

Share this post


Link to post
Share on other sites
One more thing:
It would be a good idea to declare "done" as "volatile", otherwise it may happen that it's never read beyond the first time in "otherThread"...

Share this post


Link to post
Share on other sites
Quote:
Original post by fpsgamer
Use a synchronization primitive.

*** Source Snippet Removed ***


I believe you should be also establishing an critical section when assigning to the variable in the main thread in your example. Otherwise the read operation will not be blocked during the assignment operation and vice versa.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rattenhirn
One more thing:
It would be a good idea to declare "done" as "volatile", otherwise it may happen that it's never read beyond the first time in "otherThread"...


Synchronization is a sticky issue and its easy to get wrong.

Is there any reason you've chosen not to use a mutex?

Share this post


Link to post
Share on other sites
Quote:
Original post by fpsgamer
Is there any reason you've chosen not to use a mutex?

At this point? Only because I haven't yet started the actual integration of threads into the game. I'm at the proof-of-concept stage right now.

I'd like to avoid mutexes for one thing in particular: the array I have as representation of the keyboard. The SDL event manager system doesn't seem to work unless I invoke it in the original thread, and locking/unlocking the physics thread each time I poll for input seems unnecessary and contrived.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hnefi
Quote:
Original post by fpsgamer
Is there any reason you've chosen not to use a mutex?

At this point? Only because I haven't yet started the actual integration of threads into the game. I'm at the proof-of-concept stage right now.

I'd like to avoid mutexes for one thing in particular: the array I have as representation of the keyboard. The SDL event manager system doesn't seem to work unless I invoke it in the original thread, and locking/unlocking the physics thread each time I poll for input seems unnecessary and contrived.


In case of a bool (or anything <= sizeof(void *)), as used in the above example, volatile would be enough. But keep in mind, that on single-core machine, the above example may hang, since one thread will consume all resources, not giving the other one any time slices to run.


In case of anything larger, or anything more than 1 variable, you need to synchronize.

As for lock-less programming, that's simply too tricky right now to talk about generally.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!