The Open-Source Game Development Pipeline

Providing the means and education to create games using free/libre open-source tools.

To Thread, or Not to Thread… That is the Question

Leave a comment

Hello, readers!

Today I’m going to discuss threading, and how it can affect the responsiveness of your application.

This topic was inspired by a comment made by a reader about my previous post. To sum it up, they wondered whether or not my game context was affected by potential latency caused by a “do/while” loop that was included inside of my audio code. Well… because of “threading”, it wasn’t!

So, what is threading… or, more importantly, what is a thread?

A thread is a unit of execution, usually containing a task (a set of instructions loaded into the computer’s memory) to be executed by the CPU. A thread is also a “scheduling” mechanism, which means that it is used to interface with an operating system’s scheduler. Threading guarantees that any task encapsulated by one will be added to the processor’s queue for immediate execution (sometimes simultaneously, which we call “concurrency”).

Tying this back into why it would be necessary for a “do/while” loop… how does threading enable my application to remain responsive? Well, let’s think about it.

Given the imperative nature of programs (A before B, B before C, etc.), if the application became stuck inside of a do/while loop, it would remain there until the loop finally exited. This would normally be true in a single-threaded environment.

If the function encapsulating the do/while loop were threaded, however, the application would be allowed to continue operating as it normally would, without having to worry about the looped task. This is especially useful for when certain actions need to be performed at the same time, like a punch sound firing off when a character’s “punching animation” connected with the bounding box of an enemy unit. Concurrency allows me to have my cake, and eat it too!

So, what is an example of threading? Here’s a POSIX routine that I’m using to test my audio library.

// The below is placed within the scope of my Game class.
pthread_t thread;
const char *audioFile = "test2.wav";
pthread_create(&thread, NULL, play2DAudio, (void*)audioFile);

“play2DAudio()” is a static function which has been passed into the “pthread_create()” method as a parameter for execution. This is the task that I want to be performed asynchronously.

void *play2DAudio(void* param){
    const char *fn = (const char*)param;
    const char *media = MEDIA_DIRECTORY;
    char path[100];
    strcpy(path, media);
    strcat(path, fn);
    twoDAN = new TwoDAudioNode(path);

As you can see, “play2DAudio()” takes the audioFile character string and uses it to load an audio file inside of a static instance of the “TwoDAudioNode” class. The reason this is threaded is so that loading & playing audio files (which may take a couple of cycles depending upon the size) doesn’t interfere with the Game class’ render/update loop.

Please note that only static methods and variables (unless locally declared) are able to be utilized by POSIX threads; members won’t make the cut! 😛

I don’t think one post will be suitable for covering this topic in its entirety, so consider this a little introduction to help get you started along the path of performance optimization. 🙂

If you have any questions, don’t hesitate to ask.


P.S. I’m currently learning Blender and how to animate with it. Once I get further along with my knowledge of 3D graphics, I’ll have an update on my C++ game framework.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s