I assume you are using nginx as a reverse proxy. In such case any parallel connections that come to you app are queued by operating system. You should not even count nginx in your equation because you can never predict when a connection comes. What you control though is the moment of accepting/handling it.
Truth is that usually listening for connections is handled in a single thread, in some kind of a loop. It is the handling part may or may not be done in a multi-threaded.
The simple and safe design below.
With such approach there is no need to worry about multiple threads. If a different connection comes in the middle of handling the first one then it will simply be queued and have to wait.
You can improve this if you write your app in a way that the relevant state is stored in a separate entity/database and then you may simply start several single-threaded C++ processes.
If you fork your C++ process or use a FastCGI backend you may share a single listening socket that will dispatch the incoming connections to several single-threaded C++ app instances.
I would strongly advice a multi-process approach due to the "leaky" and "crashy" nature of C++. If you have multiple processes any one of them may be restarted and / or crash without compromising the whole system.
Incidentally you get thread-safety by design if handling only one connection at a time by a process. This would mimic Node.JS web servers which have a reputation for being snappy.