将任务和线程池一起使用是否可以?

时间:2013-11-01 15:25:02

标签: c# .net multithreading task-parallel-library .net-4.5

在阅读this文章中的线程池和任务如何工作之后,我提出了这个问题 -

如果我有一个复杂的程序,其中某些模块使用tasks而某些模块使用thread pool,那么由于使用的不同,是否会出现一些调度问题?

4 个答案:

答案 0 :(得分:2)

任务通常使用线程池实现(当然也可以使用其他类型的调度程序来执行任务,这些调度程序提供不同的行为,但这是默认设置)。就正在执行的实际代码而言(假设您的任务代表正在运行的代理),确实没有太大区别。

任务只是创建一个围绕该线程池调用的包装器,以便在收集有关该异步操作的信息和处理该异步操作的结果时提供其他功能。如果您想利用其他功能,请使用任务。如果您不需要在某些特定的上下文中使用它,那么直接使用线程池没有任何问题。

混合两者,只要你没有从这些操作的结果中得到你想要的东西,根本不是问题。

答案 1 :(得分:1)

不,不存在问题 - 你们两个都没有效率。使用真正需要的东西并坚持使用模式。请记住确保您的应用程序MT安全,特别是如果您从不同的线程访问相同的资源/变量等,无论您使用哪种线程算法。

答案 2 :(得分:1)

没有。当混合方法时,实际上没有太多的记忆或性能低效;默认情况下,任务使用与线程池线程使用的相同的线程池。

混合两者的唯一显着缺点是代码库缺乏一致性。如果你选择一个,我会使用TPL,因为它有一个丰富的API来处理多线程的许多方面,并利用async / await语言功能。

由于您的使用分为模块行,因此您无需担心。

答案 3 :(得分:0)

不应该存在任何调度问题,但当然最好使用Tasks并让Framework决定如何处理预定的工作。在当前版本的框架(4.5)中,除非使用LongRunning选项,否则工作将通过ThreadPool排队,但此行为可能在将来发生变化。

结论:混合任务和ThreadPool不是问题,但对于新应用程序,建议使用Tasks而不是直接在ThreadPool上排队工作项(原因之一是ThreadPool在Windows 8运行时不可用(现代) UI应用程序)。