如果已经有太多的任务在排队,TaskFactory是否有可能长时间不运行任务?如果是这样的话,有一种方法可以配置taskfactory,使其能够更快地运行更多任务。
另外,在同一进程中同时使用TaskFactory和Threadpool.QueueUserWorkItem会有什么问题吗?我们有一些较旧的库,它们仍然使用Threadpool类。
发布于 2012-07-12 19:25:09
使用TPL,您的任务将自动进入线程池;在线程池中,线程池会记录它将同时运行的正在运行的线程的数量。过多的活动线程会降低性能,给操作系统带来管理负担。一旦达到预定义的线程数量限制,它们就会被排队。一些背景知识。
线程池从池中的一个线程开始,池管理器“注入”新的线程来处理额外的异步工作负载,直到某个限制的最大值。在一段设定的非活动时间后,如果池管理器“认为”这样做会带来更好的吞吐量,它可能会“退出”线程。在上面的例子中,池管理器限制了并发线程的数量。
您可以通过调用Thread.Pool.SetMaxThread;来设置池将创建的线程数的上限,默认值为:
1023 in Framework 4.0 in a 32-bit environment.
32768 in Framework 4.0 in a 64-bit environment.
250 per core in Framework 3.5.
25 per core in Framework 2.0.这些数字可能因硬件和操作系统而异。
之所以会出现这些数量庞大的线程(至少在.NET 4.0中是这样),是为了确保即使在某些线程被阻塞(运行一些高强度工作等)的情况下也能取得进展。
您可以通过ThreadPool.SetMinThreads设置下限。这个限制器的作用比最大限制器的作用更微妙:它指示池管理器在线程数量达到这个下限之前不要延迟线程的创建-当有阻塞的线程时,设置这个数字将提高并发性。
如果您使用的是Framework 4.0之前的版本,则不能使用TPL。你可以使用4.0并调用QueueUserWorkItem -这(乍一看)应该不会给你带来任何问题。
我希望这能帮到你。
发布于 2012-07-12 19:21:53
艾尔文。当您将要运行的任务排入队列时,这些任务将被安排使用ThreadPool中的线程运行。任务的运行数量和运行速度将取决于可用线程的数量和执行特定任务所需的时间。如果有很多队列任务,线程池可以根据需要启动新的线程,但这在很大程度上取决于可用的资源和cpu。线程池可以配置为设置默认线程数,但在大多数情况下不建议这样做。
同时使用任务和Threapool.QueueUserWorkItem应该不会有任何问题,因为默认的任务调度程序使用相同的线程池。所有将发生的情况是,您将有更多的队列任务等待由相同的线程池处理。
https://stackoverflow.com/questions/11450576
复制相似问题