Multithreading in plain C for Windows

This is a discussion on Multithreading in plain C for Windows within the C Programming forums, part of the General Programming Boards category; When the frame rate in my game drops, controls become awkward and unresponsive. To solve this problem, I've thought of ...

  1. #1
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582

    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.
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,425
    "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.
    Right 98% of the time, and don't care about the other 3%.

  3. #3
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    In your cpu intensive drawing functions, try not to draw so much. Make up and store the image of what might need, and then simply display that image/images, as needed.

    Of course, you'll still need to do some drawing - but you can save a lot of cpu cycles by using pre-made images.

  4. #4
    Math wizard
    Join Date
    Dec 2006
    Location
    USA
    Posts
    582
    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).
    High elevation is the best elevation. The higher, the better the view!
    My computer: XP Pro SP3, 3.4 GHz i7-2600K CPU (OC'd to 4 GHz), 4 GB DDR3 RAM, X-Fi Platinum sound, GeForce 460, 1920x1440 resolution, 1250 GB HDD space, Visual C++ 2008 Express

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,425
    Quote Originally Posted by ulillillia View Post
    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++.
    Right 98% of the time, and don't care about the other 3%.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. size_t vs plain int
    By monkey_c_monkey in forum C++ Programming
    Replies: 15
    Last Post: 07-12-2012, 07:07 AM
  2. plain pong
    By lambs4 in forum Game Programming
    Replies: 16
    Last Post: 10-10-2004, 01:49 PM
  3. Multithreading with the Windows API
    By Xzyx987X in forum Windows Programming
    Replies: 7
    Last Post: 11-06-2003, 11:22 PM
  4. Plain Window!
    By Shakespeare in forum Windows Programming
    Replies: 1
    Last Post: 01-20-2002, 11:35 AM
  5. Tabs in a plain Dialog
    By jinx in forum Windows Programming
    Replies: 0
    Last Post: 12-01-2001, 05:29 PM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21