Your question is very general and I haven't faced that problem yet. But I have a basic idea how this can work. In your example, the input thread need to communicate with the state thread and the state thread need to communicate with the rendering thread.
There are two concepts coming to my mind here. First, you could make use of double buffers. For example, the state thread provides its results in the front buffer. While the renderer reads them, it continues working and stores the results in the back buffer. Each time new results are available, the buffers are switched so that the newest state is read always.
Another concept that might be favorable is a queue. For example, the input thread captures the input events and simple adds the actions to a thread safe queue. The state thread can fetch them anytime and they are removed from the queue after that.
In contrast to this way of using a double buffer, the queue ensure that all input events arrive.
My personal guess is that, as you already mentioned, the lack of synchronization wouldn't be too important. Since input, state and renderer have a higher frequency then the human eye can notice (hopefully) there might be no need for synchronization. But as I already said I haven't faced this problem yet so I cannot assure that totally.