What is the best way to organize a multi-threaded architecture?

Question

C++ / C#

There is some equipment connected to the computer. The program must control the hardware and periodically send data to the server.
For each device it is launched on a control flow. The switch, through which control threads send data to the server, also runs in a separate thread.
Due to hardware errors, the control thread may terminate its work. In this case, it needs to be restarted. If new equipment is connected, a new control thread must also be launched for it.
Also, the user must be given the opportunity to complete certain flows manually.
The logic of the control flows and the switch is iterative, that is, the implementing classes have a tick method that must be called in a loop.
Attention to the question: how best to organize it all? Are there any template solutions (like a thread pool)?

Answer 1

Look, there is probably no ready-made monolithic template (more precisely, I don’t find one from my experience).
The description shows that you can use the Thread pool + Proactor + Actor model.
Instead of a thread on the device, there will be a pool of threads + a control thread, i.e. There are only two families of threads. Each device is an actor. The actor's actions are executed atomically in the required thread (main/service) by scheduling the right handler for the right thread.
Here, I'll throw in some literature:
www.gamedev.ru/code/articles/concurrency_models
https://habrahabr.ru/users/eao197/topics/ - SObjectizer is a rather interesting library.
And, yes, Alexander Taratinright, your task can also be solved, perhaps with great success, by separating the service of each device into a separate workflow. At the same time, the connection of the control process with the workers is easily and efficiently organized through the exchange of messages.
And here is the link to the messaging library - ZeroMQ .

Answer 2

Due to hardware errors, the control thread may terminate its work.

In this situation, I would generally separate it into separate processes in order to think less about possible incorrect release of resources.