Thread: Multithreading in plain C for Windows

When the frame rate in my game drops, controls become awkward and unresponsive. To solve this problem, I've thought of separating the CPU-intensive drawing routines from the other routines (controls, movement, etc.) into multiple threads. That is, I want to put all the function calls for drawing on one thread, and all the movement, controls (keyboard input basically), etc. on the main thread.

I've searched for tutorials though all I see are tutorials that use C++ or C# instead of just plain C. They also seem to be geared toward Linux, Unix, or some other operating system that is not Windows or using VC++ 2008 Express. With inconsistencies in the various tutorials, I can't tell which is which.

All I want to do is just get started. Obviously, I need to create a thread. Then I need to figure out how to temporarily pause a thread so that the drawing won't be based on old positions. This way, I resume the execution of the drawing thread when the positions have been determined.

"Plain C" under windows is not compliant with the latest C standard, so anything involving multithreading requires using non-standard functions.

You'll probably be best off using win32 API functions. CreateThread() is used to create a thread. It is rarely a good idea to pause threads (whether using windows or not). Instead, make use of mutexes, semaphores, or critical sections (all different type of objects for synchronisation, with different advantages and dsadvantages) to protect data that is shared between threads. Look up CreateMutex(), CreateSemaphore(), and InitializeCriticalSection() for information on how to create them. Follow the links for each one to learn about their usage.

If you're willing to go to C++, the latest standard does support threading. Since that standard was ratified in 2011, I'm not sure exactly how well the latest VC++ supports such features though.

By "plain C", I mean not C++ or C#, just C. Searching for things involving C tends to have C++ and C# included into the mix and that's where I get "plain C" from.

CreateThread - that sounds like something that might work. A critical section would be the checking of keyboard input. I don't think I have a use for semaphores, but mutexes almost certainly would be needed.

Premade images are used as much as absolutely possible. I prerender everything I possibly can before even the first draw is made, sometimes even before the program is even run. Even the number of pixels being drawn is reduced as much as I can. The very act of calling the function to draw is quite CPU intensive, not the actual draw itself. There are up to 2000 draw calls per frame (about 7 million pixels), or 120,000 draws per second (420 million pixels per second) for 60 fps. I typically get close to 140 fps anyway at the low end, 200 fps typical. Get in the clouds and I can get almost 300 fps. If I get far above everything, 2000+ fps is possible. Thus, frame rate is not an issue, unless I have an unexpected bug, or someone is playing my game on another computer that's inferior to mine and hasn't reduced graphics settings.

I'm not after C++ - there's nothing there that I could make use of or I can at least do it in C to some extent (the only thing of interest in C is the "new" (and the related "delete") commands for memory allocation).

Originally Posted by ulillillia

A critical section would be the checking of keyboard input. I don't think I have a use for semaphores, but mutexes almost certainly would be needed.

You need to look more closely. A critical section object under windows is a synchronisation primitive, like a mutex. The difference (under windows) is that critical sections allow synchronisation between threads in a process, while a mutex allows synchronisation between processes. The overhead of the two, in terms of impact on system resources, is very different.

I understood what you meant by "plain C" - although you actually don't properly understand the term.

Under windows, most modern C compilers are actually C++ compilers. That is certainly true of Microsoft compilers: strategically, Microsoft has decided to support C++ rather than C - particularly with respect to recent standards. Hence, if you are aiming to do multithreaded work under windows, you will be better off using C++ than C. And since the latest C++ standard does support multithreading, your code will have a chance of being portable. Albeit it will take a while for available compilers to fully support recent standards. The win32 API is largely vendor (i.e. microsoft) specific.

Also, the new and delete operators are C++, not C. So if you are using them, you are already using C++. What you are calling plain C is actually C++.