一起使用任务和线程池可以吗？答案

【问题标题】：Is it fine to use tasks and thread-pool together?一起使用任务和线程池可以吗？
【发布时间】：2013-11-01 15:25:01
【问题描述】：

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

如果我有一个复杂的程序，其中有些模块使用tasks，有些使用thread pool，是否会因为使用不同而产生一些调度问题？

【问题讨论】：

【解决方案1】：

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

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

将两者混合使用，只要您从这些操作的结果中得到您想要的结果没有问题，这根本不是问题。

【讨论】：

【解决方案2】：

没有。在混合方法时，实际上并没有太多的内存或性能低效问题；默认情况下，任务使用与线程池线程相同的线程池。

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

由于您的使用被划分为模块行，您不必担心太多。

【讨论】：

【解决方案3】：

不，不会有问题 - 你只是在这两个方面效率低下。使用真正需要的东西并坚持这种模式。请记住确保您的应用程序 MT 安全，尤其是当您从不同的线程访问相同的资源/变量等时，无论您使用哪种线程算法。

【讨论】：

【解决方案4】：

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

结论：混合任务和线程池不是问题，但对于新应用程序，建议使用任务而不是直接在线程池上排队工作项（原因之一是线程池在 Windows 8 运行时不可用（现代UI 应用程序）。

【讨论】：