The solution IS strictly sequential from the point of view of a host communication transaction. You have not explained how your multiple ADCs map to host transactions. Does a client request a reponse from a specific ADC, or any ADC? If there is a 1:1 mapping, it is even more so strictly sequential.
You need to be clear about who DRIVES what. In your host communication scheme, the control flow is driven by the clients: As long as no client connects, nothing happens, but as soon as a client connects, the client determines by its request how your target behaves. From your fragmentaric explanations, it seems to me as if the client(s) are “polling” the ADCs ver the network.
If you want your ADCs to trigger actions, you may want to invert the communication direction, ie let your target be the TCP client and initiate a communication actively as soon as an ADC has smething interesting to report (eg a significant change of reading).
Also, to me it is unclear what the nature of separate client requests is. A TCP server is designed to accept connections from separate end points concurrently, for example from multiple independent PCs. However, if all client requests all come sequentially from the same peer (such as in the “polling” case), you would not need any multithreading at all, just a server that traverses an infinite “accept-read-write-close” loop, as you will never receive a new client request while you process the current one. In that scenario, you could even leave the socket open and process all transactions sequentially over the same open connection (which has the additional benefit that you could also address security here by negotiating a session key for the duration of that cnnection and encrypting all traffic with that session key).