多线程处理通过UDP处理数据的应用程序 [英] Multithreading an application to handle data over UDP

问题描述

嘿大家好我有一个关于通过网络监听提要的应用程序的多线程的快速问题。



问题是你是否有一个应该监听数据的应用程序多个多播频道（多个是你现在真的没有多少它们可以是10个频道，它们可能是20个）是什么最有效的方式来构建这个应用程序的线程创建..你应该听的每个频道是否创建自己的线程或你应该只使用一个线程听吗？



这个问题纯粹基于应用程序设计的效率观点。



请分享您的想法

解决方案

没有。在不可预测的频道数量的情况下，这是没有意义的，只是不安全。你确实需要线程，但太多的线程只会影响吞吐量，因为线程本身有其开销。只有线程数不超过CPU核心总数，才能增加线程，从而提高系统性能。一般来说，性能不是线程的目标。







面对它，线程化有相当大的开销。如果您有4个CPU内核，而某些作业在逻辑上不需要线程，则可以将其拆分为4并改善总完成时间，但前提是工作量足够大。如果你将它拆分为20个线程，可能需要更长的时间才能完成。

-SA

Hey everybody. I have a quick question on multithreading for an application that listens for feeds over a network.

The question is if you have an app that is supposed to listen for data over multiple multicast channels (multiple being you don't really now how many they can be 10 channels they could be 20) whats the most efficient way to build this application in terms of thread creation.. Should each channel you are listening on create its own thread or should you listen using only a single thread?

The question is based purely on an efficiency standpoint for the design of the app.

Please share your thoughts

解决方案

No. It would not make sense in the case of unpredictable number of channels, and simply unsafe. You do need threads, but too many threads would only compromise throughput, because threading itself has its overhead. Performance of the system can grow with adding threads only with the number of the threads not exceeding the total number of CPU cores. Generally, performance was not a goal of threading.

[EDIT]

Face it, threading itself has its considerable overhead. If you have 4 CPU cores and some job not logically requiring threading, you can split it into 4 and improve total completion time, but only if the work is big enough. If you split it between 20 thread, it may take more time to complete.

—SA

这篇关于多线程处理通过UDP处理数据的应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！