需要维持秩序的多线程作业
我有一个 ac/c++ 进程，它有一个很长的队列，并且该队列中的每个元素都需要 发送到多个（TCP）服务器。单线程是一个可行的选项，但速度很慢。
我需要实现一个多线程解决方案。我的进程事先不知道数量 服务器数量。第一个想法是为每个服务器创建一个线程。管理器线程读取 队列中的新元素找到目的地并分派到与目的地匹配的线程。
一个重要的说明。工作可能是依赖的。如果 job_5 未完成，我不想执行 job_10。 订单需要维护。
首先我想听听您对这个问题的看法。其次，我正在寻找 C++ 实现以供参考。第三，我正在寻找描述类似问题的书籍/资源。
I have a c/c++ process that has a long queue and every element in this queue needs to be
sent to a multiple (TCP) servers. The single thread is an option that works, however it is slow.
I need to implement a multithreaded solution. My process does not know in advance the number
of servers. The first idea is to create one thread for every server. A manager thread reads
the new element in the queue finds the destination and dispatches to the thread that matches the destination.
One important note. Jobs might be dependent. I don't want to executed job_10 if job_5 is not completed. Order needs to be maintained.
First of all I would like your opinion on the issue. Second I am searching for C++ implementations for reference. Third I am looking for books/sources that describe similar issues.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你看过
boost asio?它支持“线程池”的概念，因此您可以拥有一个异步处理大量连接的线程池，而不是每个服务器只有一个线程（即同步）。性能也不算太差...Have you looked at
boost asio? It supports the concept of a "thread pool", so rather than a single thread per server (that is synchronous), you can have a pool of threads handling a large number of connections asynchronously. Performance isn't too bad either...您是如何得出需要多线程解决方案的结论的？当您说您的单线程解决方案“慢”时，您是什么意思？您的意思是在将项目发送到服务器时其他处理（可能是 UI 内容？）被阻止？还是整个过程花费的时间太长？
您对这个问题的描述不明确：每个项目是否需要发送到所有服务器，还是只发送到一个服务器？看起来只有一个，但我不确定。如果必须发送给所有人，那么多线程解决方案的复杂度就会大大增加。
您可以在发送项目后将其从队列中删除，还是需要等待服务器的确认？如果您必须等待，那么您的队列管理将变得棘手 - 在确认之前您无法删除该项目，因此您必须以某种方式将其标记为待处理，并且从队列中选取下一个项目的线程将需要确保它不会选择待处理的项目。当项目成功发送后，必须将其从队列中删除，这意味着对队列的并发写入访问。
你如何处理错误？如果无法发送某个项目，它是否会保留在队列中以供稍后重试，或者是否会移动到失败列表，或者只是记录并丢弃？在多线程系统中，您将异步了解失败，这意味着对错误处理过程的并发写入访问。
你说你的进程事先不知道有多少台服务器。这个数字在处理过程中可以改变吗？
无论如何，请考虑多线程，但您可能会发现“缓慢”的单线程解决方案最能满足您的业务需求 - 易于实现且可靠。如果没有，那么希望其中一些问题对您有所帮助。
How did you arrive at the conclusion that you need a multithreaded solution? What do you mean when you say that your single-threaded solution is "slow"? Do you mean that other processing (perhaps UI stuff?) is held up while the items are sent to the server? Or does the whole process just take too long?
Your description is ambiguous on this question: does each item need to be sent to all servers, or just to one? Seems like just one, but I'm not sure. If it must be sent to all, then the complexity of a multi-threaded solution increases greatly.
Can you remove an item from the queue once it's been sent, or do you need to wait for an acknowledgement from the server? If you must wait then your queue management will become tricky - you can't remove the item until it's been acknowledged, and so you'll have to mark it as pending somehow, and the thread that picks the next item from the queue will need to be sure it doesn't pick a pending item. And when the item has been sent successfully it will have to be removed from the queue, and this implies concurrent write access to the queue.
How do you handle errors? If an item can't be sent does it stay in the queue for later retry, or is it moved to a failed list, or is it just logged and discarded? In a multithreaded system you'll learn of the failure asynchronously, and that implies concurrent write access to the error handling procedure.
You say that your process doesn't know in advance how many servers there are. Can this number change during processing?
By all means look into multithreading, but you may find that your "slow" single-threaded solution serves your business needs best - easy to implement, and reliable. If not, then hopefully some of these questions will be helpful to you.