我正在编写一个服务器,当请求传入时,我将每个动作分支到一个线程中.我这样做是因为几乎每个请求都进行数据库查询.我正在使用线程池库来减少线程的构造/销毁.
我的问题是 - 像这样的I/O线程有什么好的截止点？我知道这只是一个粗略的估计,但我们是在说几百个？成千上万的？
谢谢大家的回复,似乎我只是要测试它以找出我的线程数上限.问题是:我怎么知道我达到了这个上限？究竟应该测量什么？
我有一个联网Linux应用程序,它接收来自多个目的地的RTP流,进行非常简单的数据包修改,然后将流转发到最终目的地.
如何确定处理数据所需的线程数？我想,我无法为每个RTP流打开一个线程,因为可能有数千个.我应该考虑CPU核心的数量吗？还有什么重要的？谢谢.
我正在使用VB9(VS2008).
我已经创建了一个定期为某些文件夹编制索引的Windows服务.
有没有办法可以根据当前系统状态对CPU使用率设置上限,即,如果系统处于空闲状态,则线程可以根据需要使用CPU,但是如果有其他程序/进程正在运行那么它应该以不会使系统变慢的方式使用CPU.
我现在正在学习如何编写mutithreaded程序,我有一个假设的问题,关于程序的最佳线程数.
我来描述两个场景.
第一种情况是我有一个容易多线程的程序,但每个线程将要做很多工作(每个线程的执行时间大约为几秒).
第二种情况是我有一个程序也很容易多线程,但每个线程的执行时间非常短,大约为毫秒.
在这些场景中的任何一个场景中,对程序进行多线程处理的最有效方法是什么？它是创建与我的系统内存允许的一样多的线程,还是在创建新线程之前等待线程完成,这样我在任何时候都只能运行4个工作线程的格言.
一方面,许多线程可能会遇到线程在线程之间切换的开销问题(根据我的理解,这不是一个如此严重的开销).另一方面,如果我限制运行的线程数,这意味着我将运行额外的检查条件并锁定和解锁计数器变量以跟踪运行的线程数,并在旧线程完成时创建新线程.
我可以看到,如果有很多小线程,最好简单地用尽可能多的线程重载我的系统,因为在线程完成运行之前不会有太多的线程切换.这将节省我不断跟踪线程数量的开销.
此外,如果只有几个大线程(少数,我的意思是大约一百个大线程),跟踪线程是有意义的,这样我们就可以保持线程处于最佳数量,这样就会有非常多的线程切换(因为开销会更大,因为我们可能会在单个线程完成之前多次切换).
那么这些假设对于每个案例都是正确的,还是存在一种在所有情况下都是正确的做事的普遍方式？
注意:这是假设一个多核心系统(现在,让我们忽略超线程)并让我们忽略与mutithreading相关的任何典型问题(假设所有线程都有私有写入位置,并且只能从公共位置读取,锁定和解锁只发生当递增或递减计数器的活动线程数时).
谢谢,
-Faken