Update and render in separate threads

Question

I'm creating a simple 2D game engine and I want to update and render the sprites in different threads, to learn how it is done.

I need to synchronise the update thread and the render one. Currently, I use two atomic flags. The workflow looks something like:

Thread 1 -------------------------- Thread 2
Update obj ------------------------ wait for swap
Create queue ---------------------- render the queue
Wait for render ------------------- notify render done
Swap render queues ---------------- notify swap done

In this setup I limit the render thread's FPS to the update thread's FPS. Besides I use sleep() to limit both render and update thread's FPS to 60, so the two wait functions won't wait much time.

The problem is:

The average CPU usage is around 0.1%. Sometimes it's go up to 25% (in a quad core PC). It means that a thread is waiting for the other because the wait function is a while loop with a test and set function, and a while loop will use all your CPU resources.

My first question is: is there another way to synchronise the two threads? I noticed that std::mutex::lock don't use the CPU while it is waiting to lock a resource so it isn't a while loop. How does it work? I can't use std::mutex because I will need to lock them in one thread and unlock in another thread.

The other question is; since the program runs always at 60 FPS why does sometimes its CPU usage jumps to 25%, meaning that one of the two wait is waiting a lot? (the two threads are both limited to 60fps so they ideally won't need a lot of synchronisation).

Edit: Thanks for all the replies. First I want to say I don't start a new thread each frame for render. I start both update and render loop at the beginning. I think multithreading can save some time : I have the following functions: FastAlg() and Alg(). Alg() is both my Update obj and render obj and Fastalg() is my "send render queue to" renderer" ". In a single thread :

Alg() //update 
FastAgl() 
Alg() //render

In two thread:

Alg() //update  while Alg() //render last frame
FastAlg() 

So maybe multithreading can save same time. (actually in a simple math application it does, where alg is a long algorithm amd fastalg a faster one)

I know that sleep isn't a good idea, although I ve never have problems. Will this will better?

While(true) 
{
   If(timer.gettimefromlastcall() >= 1/fps)
   Do_update()
}

But this will be a infinite while loop that will use all the CPU. Can I use sleep(a number < 15) to limit the usage? In this way it will run at, for example, 100 fps, and the update function will be called just 60 times per second.

To synchronise the two threads I will use waitforsingleobject with createSemaphore so I will able to lock and unlock in different thread (whitout using a while loop), won't I?

Answer 1

For a simple 2D engine with sprites, a single-threaded approach is perfectly good. But since you want to learn how to do multithreading, you should learn to do it correctly.

Do not

• Use 2 threads that run more or less lock-step, implementing a single-threaded behavior with several threads. This has the same level of parallelism (zero) but adds overhead for context switches and synchronization. Plus, the logic is harder to grok.
• Use sleep to control the frame rate. Never. If someone tells you to, hit them.
  First, not all monitors run at 60Hz. Second, two timers ticking at the same rate running side by side will always eventually get out of sync (drop two pingpong balls on a table from the same height, and listen). Third, sleep is by design neither accurate nor reliable. Granularity may be as bad as 15.6ms (in fact, the default on Windows^[1]), and a frame is only 16.6ms at 60fps, which leaves a mere 1ms for everything else. Plus, it's hard to get 16.6 to be a multiple of 15.6...
  Also, sleep is allowed to (and will sometimes!) return only after 30 or 50 or 100 ms, or an even longer time.
• Use std::mutex to notify another thread. This is not what it's for.
• Assume that TaskManager is any good at telling you what's going on, especially judging from a number like "25% CPU", which could be spent in your code, or within the usermode driver, or somewhere else.
• Have one thread per high level component (there are of course some exceptions).
• Create threads at "random times", ad hoc, per task. Creating threads can be surprisingly expensive and they can take a surprisingly long time before they are acutally doing what you told them (especially if you have a lot of DLLs loaded!).

Do

• Use multithreading to have things run asynchronously as much as you can. Speed is not the main idea of threading, but doing things in parallel (so even if they take longer alltogether, the sum of all is still less).
• Use vertical sync to limit the frame rate. That is the only correct (and non-failing) way to do it. If the user overrides you in the display driver's control panel ("force off"), then so be it. After all it's his computer, not yours.
• If you need to "tick" something at regular intervals, use a timer. Timers have the advantage of having a much better accuracy and reliability as compared to sleep^[2]. Also, a recurring timer accounts for time correctly (including time that passes in between) whereas sleeping for 16.6ms (or 16.6ms minus measured_time_elapsed) doesn't.
• Run physics simulations that involve numeric integration at a fixed time step (or your equations will explode!), interpolate graphics between steps (this may be an excuse for a separate per-component-thread, but it can also be done without).
• Use std::mutex to have only one thread access a resource at a time ("mutually exclude"), and to comply with the weird semantics of std::condition_variable.
• Avoid having threads compete for resources. Lock as little as necessary (but none less!) and hold locks only as long as absolutely necessary.
• Do share read-only data between threads (no cache issues, and no locking necessary), but do not concurrently modify data (needs sync and kills the cache). That includes modifying data that is nearby a location someone else might read.
• Use std::condition_variable to block another thread until some condition is true. The semantics of std::condition_variable with that extra mutex are admittedly pretty weird and twisted (mostly for historic reasons inherited from POSIX threads), but a condition variable is the correct primitive to use for what you want.
  In case you find std::condition_variable too weird to be comfortable with it, you can as well simply use a Windows event (slightly slower) instead or, if you are courageous, build your own simple event around NtKeyedEvents (involves scary low level stuff). As you use DirectX, you're already bound to Windows anyway, so loss of portability shouldn't a biggie.
• Break work into reasonably-sized tasks that are run by a fixed-size worker thread pool (no more than one per core, not counting hyperthreaded cores). Let finishing tasks enqueue dependent tasks (free, automatic synchronization). Make tasks that have at least a few hundred non-trivial operations each (or one lenghty blocking operation like a disk read). Prefer cache-contiguous access.
• Create all threads at program start.
• Take advantage of asynchronous functions that the OS or the graphics API offers for better/additional parallelism, not only on the program level but also on the hardware (think PCIe transfers, CPU-GPU parallelism, disk DMA, etc.).
• 10,000 other things that I've forgotten to mention.

---

[1] Yes, you can set the scheduler's rate down to 1ms, but this is frowned upon as it causes a lot more context switches, and consumes a lot more power (in a world where more and more devices are mobile devices). It also isn't a solution since it still does not make sleep any more reliable.
[2] A timer will boost the thread's priority, which will allow it to interrupt another equal-priority thread mid-quantum and be scheduled first, which is a quasi-RT behavior. It is of course not true RT, but it comes very close. Waking from sleep merely means that the thread becomes ready to be scheduled at some time, whenever that may be.

Answer 2

I am not sure what you want to achieve by limiting the FPS of the Update and Render both to 60. If you limit them to the same value, you could have just put them in the same thread.

The goal when separating Update and Render in different threads is to have both "almost" independent of one another, so that the GPU can render 500 FPS and the Update logic still goes at 60 FPS. You do not achieve a very high performance gain by doing so.

But you said you just wanted to know how it works, and it's fine. In C++, a mutex is a special object that is used to lock access to certain resources for other threads. In other words, you use a mutex to make sensible data accessible by only one thread at the time. To do so, it is quite simple:

std::mutex mutex;
mutex.lock();
// Do sensible stuff here...
mutex.unlock();

Source: http://en.cppreference.com/w/cpp/thread/mutex

EDIT: Make sure your mutex is class or file-wide, as in the link given, or else each thread will create its own mutex and you will not achieve anything.

The first thread to lock the mutex will have access to the code inside. If a second thread tries to call the lock() function, it will block until the first thread unlocks it. So a mutex is a blocing function, unlike a while loop. Blocking functions will not put stress on the CPU.