Multithreaded input with mutex not smooth (as expected) - c++

Question

I am currently developing a 3D engine from scratch (again) as I wanted to use more modern techniques (and frankly, my previous design was crap). Now I am in the process of implementing my input thread.
Now that I am more experienced I know that if I write to the same variable from my input thread and my rendering/main thread then I will get data races so I decided to use mutexes(mutices?) to lock data that could be written to in different threads, but this is causing an unacceptable bug: mouse input isn't smooth any more :/
I did kind of expect that though, I just thought my thinking might be off.
Now I am stuck at a crossroads because I don't know how to go about fixing this issue!
The variable that I am writing to from both threads is x_rel and y_rel which is mouse position relative to last position when I received an event.
The input thread sets the variables and the rendering/main thread resets them to 0.0 when it is finished with them. This works fine, but as I said, this gives me very rigid mouse motion.
My question here is, what can I do to get smooth input while still being race safe across threads?
Here is my mutex definition (it is global):
std::mutex mouse_mutex;
Here is the code that I use to get the mouse events:
void input_thread_func(application &app, const bool &running, double &x_rel, double &y_rel){
while(running){
application::event ev = app.get_input();
switch(ev.type){
case events::mouse_motion :{
if(mouse_mutex.try_lock()){
x_rel = ev.xrel;
y_rel = ev.yrel;
mouse_mutex.unlock();
}
break;
}
default:
break;
}
}
}
And here is my main function:
int main(int argc, char *argv[]){
/* all my init stuff */
application app;
bool running = true;
double x_rel = 0.0, y_rel = 0.0;
std::thread input_thread(
input_thread_func,
std::ref(app), std::cref(running)
std::ref(x_rel), std::ref(y_rel)
);
double multiplier = /* whatever I like */;
while(running){
/* check input data */
if(mouse_mutex.try_lock()){
update_camera(x_rel * multiplier, y_rel * multiplier);
app.set_mouse_pos(0, 0);
x_rel = 0.0; y_rel = 0.0;
mouse_mutex.unlock();
}
/* do rendering stuff */
}
}

Answer 1

This is my understanding of your problem:
Basically, you have 2 threads, one dealing with mouse events coming from the system, and one taking care of rendering duties. As far as I understand, the later needs the most recent mouse position in order to compute an accurate set of camera matrices. However, because of the nature of the input device, the event thread is flooded with mouse position events: the system polls the device fast enough to get many updates per rendering frame, and these updates get pushed back to the event thread. That thread having only that task to do, it will constantly lock/unlock the mouse mutex while processing these events, and the odds of having that lock held by the event thread is high when the rendering thread actually wants to get ahold of it.
There are two possible problems coming out of your current setup:
either the rendering thread needs all the mouse updates, and thus you'd need to implement an event queue between that thread and the event thread to keep track of all of them, then you'd be essentially filtering mouse events to dispatch them to rendering:
setup a mouse event queue between those threads, and just push mouse events from the input queue to that new queue.
have rendering check the mouse queue at each frame, and do as many camera updates as necessary, or better yet - as suggested in the comments, combine all these events in one single camera update, if possible. You should try putting that computation in the event thread, in order to reduce load on rendering.
or rendering only needs the latest event (as it seems to be doing), in which case you need to update the mutexed data structure with the latest one only (thus reducing contention on that mutex).
To recap, depending on how the camera update function works wrt. mouse events, you will probably have to change it to work with only one set of absolute coordinates built cumulatively from all the relative events (maybe you can get them directly from the mouse event structure?), and only update the mutexed data once per event stream.
Note:
You may also check how other engines do it: the IdTech2 (Quake I/II) series of engines are monothreaded, but they're still a good source of inspiration. Each frame, these
deal with all mouse inputs in one go. During a frame render, a first routine is called (In_Move,HandleEvents, or some other function, depending on the backend, see the sys_* files) to check all the events and update all the related structures. When the rendering code (R_RenderFrame) is invoked, there're no contention on these structures anymore. You probably want to "emulate" the same behaviour, by making sure that rendering isn't held back by one or more mutexes. A possible solution has been described above for mouse input, and can certainly be extended to handle other type of input devices.